HUT, Falt. of IT Dept. of SE, 2001 SE-I.1
Nhập môn Công nghệ học Phần mềm
(Introduction to Software Engineering)
Department of Software Engineering Faculty of Information Technology
Hanoi University of Technology TEL: 04-8682595 FAX: 04-8692906
Email: [email protected]
HUT, Falt. of IT Dept. of SE, 2001 SE-I.2
Cấu trúc môn học
• 45 tiết + 1 Đồ án môn học • Cần những kiến thức căn bản về CNTT • Cung cấp những nguyên lý chung về
Công nghệ học Phần mềm (CNHPM) • Cung cấp kiến thức để học các môn
chuyên ngành hẹp như Phân tích và thiết kế phần mềm, Xây dựng và đánh giá phần mềm, Quản trị dự án phần mềm,...
HUT, Falt. of IT Dept. of SE, 2001 SE-I.3
Cấu trúc môn học (tiếp)
• Nội dung: gồm 6 phần với 11 chương – Giới thiệu chung về CNHPM (3 buổi) – Quản lý dự án PM (2b) – Yêu cầu người dùng (1b) – Thiết kế và lập trình (2b) – Kiểm thử và bảo trì (2b) – Chủ đề nâng cao và tổng kết (1b+1b)
• Đánh giá: Thi hết môn + Đồ án môn học
HUT, Falt. of IT Dept. of SE, 2001 SE-I.4
Tài liệu tham khảo
• R. Pressman, Software Engineering: A Practioner’s Approach. 5th Ed., McGraw-Hill, 2001
• R. Pressman, Kỹ nghệ phần mềm. Tập 1, 2, 3. NXB Giáo dục, Hà Nội, 1997 (Người dịch: Ngô Trung Việt)
• I. Sommerville, Software Engineering. 5th Ed., Addison-Wesley, 1995
• K. Kawamura, Nhập môn Công nghệ học Phần mềm. NXB Kinki-Kagaku, Tokyo, 2001 (Tiếng Nhật)
HUT, Falt. of IT Dept. of SE, 2001 SE-I.5
Phần I Giới thiệu chung về CNHPM Chương 1: Bản chất phần mềm
1.1 Định nghĩa chung về phần mềm 1.2 Kiến trúc phần mềm 1.3 Các khái niệm 1.4 Đặc tính chung của phần mềm 1.5 Thế nào là phần mềm tốt ? 1.6 Các ứng dụng phần mềm
HUT, Falt. of IT Dept. of SE, 2001 SE-I.6
1.1. Định nghĩa chung về phần mềm
• Phần mềm (Software - SW) như một khái niệm đối nghĩa với phần cứng (Hardware - HW), tuy nhiên, đây là 2 khái niệm tương đối
• Từ xưa, SW như thứ được cho không hoặc bán kèm theo máy (HW)
• Dần dần, giá thành SW ngày càng cao và nay cao hơn HW
HUT, Falt. of IT Dept. of SE, 2001 SE-I.7
Các đặc tính của SW và HW HW
• Vật “cứng” • Kim loại • Vật chất • Hữu hình • Sản xuất công nghiệp bởi máy móc là chính
• Định lượng là chính • Hỏng hóc, hao mòn
SW • Vật “mềm” • Kỹ thuật sử dụng • Trừu tượng • Vô hình • Sản xuất bởi con người là chính
• Định tính là chính • Không hao mòn
HUT, Falt. of IT Dept. of SE, 2001 SE-I.8
Định nghĩa 1: Phần mềm là
• Các lệnh (chương trình máy tính) khi được thực hiện thì cung cấp những chức năng và kết quả mong muốn
• Các cấu trúc dữ liệu làm cho chương trình thao tác thông tin thích hợp
• Các tư liệu mô tả thao tác và cách sử dụng chương trình
HUT, Falt. of IT Dept. of SE, 2001 SE-I.9
SW đối nghĩa với HW
• Vai trò SW ngày càng thể hiện trội • Máy tính là . . . chiếc hộp không có SW • Ngày nay, SW quyết định chất lượng một hệ thống máy tính (HTMT), là chủ đề cốt lõi, trung tâm của HTMT
• Hệ thống máy tính gồm HW và SW
HUT, Falt. of IT Dept. of SE, 2001 SE-I.10
Định nghĩa 2
Trong một hệ thống máy tính, nếu trừ bỏ đi các thiết bị và các loại phụ kiện thì phần còn lại chính là phần mềm (SW)
• Nghĩa hẹp: SW là dịch vụ chương trình để tăng khả năng xử lý của phần cứng của máy tính (như hệ điều hành - OS)
• Nghĩa rộng: SW là tất cả các kỹ thuật ứng dụng để thực hiện những dịch vụ chức năng cho mục đích nào đó bằng phần cứng
HUT, Falt. of IT Dept. of SE, 2001 SE-I.11
SW theo nghĩa rộng
• Không chỉ SW cơ bản và SW ứng dụng • Phải gồm cả khả năng, kinh nghiệm thực tiễn và kỹ năng của kỹ sư (người chế ra phần mềm): Know-how of Software Engineer
• Là tất cả các kỹ thuật làm cho sử dụng phần cứng máy tính đạt hiệu quả cao
HUT, Falt. of IT Dept. of SE, 2001 SE-I.12
Phần mềm là gì ? Nhóm các Kỹ thuật,
Phương pháp luận
Nhóm các chương trình
Nhóm các tư liệu
Kinh nghiệm kỹ sư, know-how
HUT, Falt. of IT Dept. of SE, 2001 SE-I.13
Nhóm các kỹ thuật, phương pháp luận
• Các khái niệm và trình tự cụ thể hóa một hệ thống
• Các phương pháp tiếp cận giải quyết vấn đề • Các trình tự thiết kế và phát triển được chuẩn
hóa • Các phương pháp đặc tả yêu cầu, thiết kế hệ thống, thiết kế chương trình, kiểm thử, toàn bộ quy trình quản lý phát triển phần mềm
HUT, Falt. of IT Dept. of SE, 2001 SE-I.14
• Là phần giao diện với phần cứng, tạo thành từ các nhóm lệnh chỉ thị cho máy tính biết trình tự thao tác xử lý dữ liệu
• Phần mềm cơ bản: với chức năng cung cấp môi trường thao tác dễ dàng cho người sử dụng nhằm tăng hiệu năng xử lý của phần cứng (ví dụ như OS là chương trình hệ thống)
• Phần mềm ứng dụng: dùng để xử lý nghiệp vụ thích hợp nào đó (quản lý, kế toán, . . .), phần mềm đóng gói, phần mềm của người dùng, . . .
Nhóm các chương trình
HUT, Falt. of IT Dept. of SE, 2001 SE-I.15
Nhóm các tư liệu
• Những tư liệu hữu ích, có giá trị cao và rất cần thiết để phát triển, vận hành và bảo trì phần mềm
• Để chế ra phần mềm với độ tin cậy cao cần tạo ra các tư liệu chất lượng cao: đặc tả yêu cầu, mô tả thiết kế từng loại, điều kiện kiểm thử, thủ tục vận hành, hướng dẫn thao tác
HUT, Falt. of IT Dept. of SE, 2001 SE-I.16
Những yếu tố khác
• Sản xuất phần mềm phụ thuộc rất nhiều vào con người (kỹ sư phần mềm). Khả năng hệ thống hóa trừu tượng, khả năng lập trình, kỹ năng công nghệ, kinh nghiệm làm việc, tầm bao quát, . . .: khác nhau ở từng người
• Phần mềm phụ thuộc nhiều vào ý tưởng (idea) và kỹ năng (know-how) của người/nhóm tác giả
HUT, Falt. of IT Dept. of SE, 2001 SE-I.17
1.2 Kiến trúc phần mềm 1.2.1 Phần mềm nhìn từ cấu trúc phân cấp • Cấu trúc phần mềm là cấu trúc phân cấp
(hierarchical structure): mức trên là hệ thống (system), dưới là các hệ thống con (subsystems)
• Dưới hệ thống con là các chương trình • Dưới chương trình là các Modules hoặc
Subroutines với các đối số (arguments)
HUT, Falt. of IT Dept. of SE, 2001 SE-I.18
Kiến trúc phần mềm System
Subsystem Subsystem
Program Program
Module Module Subroutine
Master files
Temporary files
Arguments Arguments
Job unit
Jobstep unit
Member unit Common Module
≈
≈
HUT, Falt. of IT Dept. of SE, 2001 SE-I.19
1.2.2 Phần mềm nhìn từ cấu trúc và thủ tục
• Hai yếu tố cấu thành của phần mềm – Phương diện cấu trúc – Phương diện thủ tục
• Cấu trúc phần mềm: biểu thị kiến trúc các chức năng mà phần mềm đó có và điều kiện phân cấp các chức năng (thiết kế cấu trúc)
• Thiết kế chức năng: theo chiều đứng (càng sâu càng phức tạp) và chiều ngang (càng rộng càng nhiều chức năng, qui mô càng lớn)
HUT, Falt. of IT Dept. of SE, 2001 SE-I.20
Cấu trúc phần mềm
Fuction A
Function B Function C
Function D Function E Function F
Cấu trúc chiều ngang (Horizontal structure)
Cấu trúc chiều đứ
ng (Vertical structure)
HUT, Falt. of IT Dept. of SE, 2001 SE-I.21
Thủ tục (procedure) phần mềm
• Là những quan hệ giữa các trình tự mà phần mềm đó có
• Thuật toán với những phép lặp, rẽ nhánh, điều khiển luồng xử lý (quay lui hay bỏ qua)
• Là cấu trúc lôgic biểu thị từng chức năng có trong phần mềm và trình tự thực hiện chúng
• Thiết kế cấu trúc trước rồi sang chức năng
HUT, Falt. of IT Dept. of SE, 2001 SE-I.22
1.3 Các khái niệm
• Khi chế tác phần mềm cần nhiều kỹ thuật – Phương pháp luận (Methodology): những chuẩn mực cơ bản để chế tạo phần mềm với các chỉ tiêu định tính
– Các phương pháp kỹ thuật (Techniques): những trình tự cụ thể để chế tạo phần mềm và là cách tiếp cận khoa học mang tính định lượng
• Từ phương pháp luận triển khai đến kỹ thuật
HUT, Falt. of IT Dept. of SE, 2001 SE-I.23
Các khái niệm (Software concepts)
• Khái niệm tính môđun (modularity concept)
• Khái niệm chi tiết hóa dần từng bước (stepwise refinement concept)
• Khái niệm trừu tượng hóa (abstraction concept): về thủ tục, điều khiển, dữ liệu
• Khái niệm che giấu thông tin (information hiding concept)
• Khái niệm hướng đối tượng (object oriented)
HUT, Falt. of IT Dept. of SE, 2001 SE-I.24
Từ phương pháp luận phần mềm sang kỹ thuật phần mềm
Tính Môđun
Chi tiết hóa dần
Trừu tượng hóa (Che giấu t.tin)
Phân tích cấu trúc
Thiết kế cấu trúc
Lập trình cấu trúc
Dữ liệu trừu tượng
Hướng đối tượng Khái niệm phần mềm
HUT, Falt. of IT Dept. of SE, 2001 SE-I.25
1.3.1 Tính môđun (Modularity) • Là khả năng phân chia phần mềm thành các môđun ứng với các chức năng, đồng thời cho phép quản lý tổng thể: khái niệm phân chia và trộn (partion and merge)
• Hai phương pháp phân chia môđun theo chiều – sâu (depth, thẳng đứng): điều khiển phức tạp dần – rộng (width, nằm ngang): môđun phụ thuộc dần
• Quan hệ giữa các môđun: qua các đối số (arguments)
HUT, Falt. of IT Dept. of SE, 2001 SE-I.26
Chuẩn phân chia môđun
Tính độc lập kém
dần
Điều khiển phức tạp dần
SW Phân chia chiều rộng
Phân chia chiều sâu
Cấu trúc rộng chiều ngang
Cấu trúc sâu chiều đứng
HUT, Falt. of IT Dept. of SE, 2001 SE-I.27
1.3.2 Chi tiết hóa từng bước Cách tiếp cận từ trên xuống (top-down
approach)
Ngôn ngữ chương trình
Chi tiết hóa
từng bước
Thế giới bên ngoài
Đặc tả yêu cầu
Trừu tượng hóa mức cao: Thế giới bên ngoài, trạng thái chưa rõ ràng
Trừu tượng hóa mức trung gian: Xác định yêu cầu và đặc tả những định nghĩa yêu cầu
Trừu tượng hóa mức thấp: Từng lệnh của chương trình được viết bởi ngôn ngữ thủ tục nào đó
HUT, Falt. of IT Dept. of SE, 2001 SE-I.28
Ví dụ: Trình tự giải quyết vấn đề từ mức thiết kế chương trình đến mức lập trình
• Bài toán: từ một nhóm N số khác nhau tăng dần, hãy tìm số có giá trị bằng K (nhập từ ngoài vào) và in ra vị trí của nó
• Giải từng bước từ khái niệm đến chi tiết hóa từng câu lệnh bởi ngôn ngữ lập trình nào đó
• Chọn giải thuật tìm kiếm nhị phân (pp nhị phân)
HUT, Falt. of IT Dept. of SE, 2001 SE-I.29
Cụ thể hóa thủ tục qua các chức năng
Bài toán đã cho Nhập giá trị K
Nhận giá trị nhóm N số
Tìm kiếm giá trị (pp nhị phân)
In ra vị trí (nếu có)
HUT, Falt. of IT Dept. of SE, 2001 SE-I.30
Cụ thể hóa bước tiếp theo
Tìm kiếm giá trị (pp nhị phân)
Xác lập phạm vi mảng số
Lặp lại xử lý tìm kiếm giá trị K trong phạm vi tìm kiếm
Tìm vị trí giữa phân đôi mảng
So sánh K với giá trị giữa
Đặt lại phạm vi tìm kiếm
Lặp lại tìm kiếm K trong phạm vi tìmkiếm
HUT, Falt. of IT Dept. of SE, 2001 SE-I.31
Mức mô tả chương trình (bằng PDL) Bắt đầu Đọc K Nhận giá trị cho mảng 1 chiều A(I), (I =1, 2, . . . ,.N) MIN = 1 MAX = N DO WHILE (Có giá trị bằng K không, cho đến khi MIN > MAX) Lấy MID = (MIN + MAX) / 2 IF A(MID) > K THEN MAX = MID - 1 ELSE IF A(MID) < K THEN MIN = MID + 1 ELSE In giá trị MID ENDIF ENDIF ENDDO KếtThúc
HUT, Falt. of IT Dept. of SE, 2001 SE-I.32
1.3.3 Khái niệm Che giấu thông tin
• Để phân rã phần mềm thành các môđun một cách tốt nhất, cần tuân theo nguyên lý che giấu thông tin: “các môđun nên được đặc trưng bởi những quyết định thiết kế sao cho mỗi môđun ẩn kín đối với các môđun khác” [Parnas1972]
• Rất hữu ích cho kiểm thử và bảo trì phần mềm
HUT, Falt. of IT Dept. of SE, 2001 SE-I.33
Khái niệm Trừu tượng hóa
• Abstraction cho phép tập trung vấn đề ở mức tổng quát, gạt đi những chi tiết mức thấp ít liên quan
• 3 mức trừu tượng – Trừu tượng thủ tục: dãy các chỉ thị với chức năng đặc thù và giới hạn nào đó
– Trừu tượng dữ liệu: tập hợp dữ liệu mô tả đối tượng dữ liệu nào đó
– Trừu tượng điều khiển: Cơ chế điều khiển chương trình không cần đặc tả những chi tiết bên trong
• Ví dụ: Mở cửa. Thủ tục: Mở gồm . . .; Dữ liệu: Cửa là . . .
HUT, Falt. of IT Dept. of SE, 2001 SE-I.34
1.4 Đặc tính chung của phần mềm • Là hàng hóa vô hình, không nhìn thấy được • Chất lượng phần mềm: không mòn đi mà có
xu hướng tốt lên sau mỗi lần có lỗi (error/bug) được phát hiện và sửa
• Phần mềm vốn chứa lỗi tiềm tàng, theo quy mô càng lớn thì khả năng chứa lỗi càng cao
• Lỗi phần mềm dễ được phát hiện bởi người ngoài
HUT, Falt. of IT Dept. of SE, 2001 SE-I.35
Đặc tính chung của phần mềm (tiếp)
• Chức năng của phần mềm thường biến hóa, thay đổi theo thời gian (theo nơi sử dụng)
• Hiệu ứng làn sóng trong thay đổi phần mềm • Phần mềm vốn chứa ý tưởng và sáng tạo của
tác giả/nhóm làm ra nó • Cần khả năng “tư duy nhị phân” trong xây dựng, phát triển phần mềm
• Có thể sao chép rất đơn giản
HUT, Falt. of IT Dept. of SE, 2001 SE-I.36
1.5 Thế nào là phần mềm tốt ?
Hiệu suất xử lý Các chỉ tiêu cơ bản
Tính dễ hiểu
Thời gian (Phần cứng phát triển)
Yếu tố
khái niệm phần mềm tốt
Đặc trưng gần đây
HUT, Falt. of IT Dept. of SE, 2001 SE-I.37
1.5.1 Các chỉ tiêu cơ bản
• Phản ánh đúng yêu cầu người dùng (tính hiệu quả - effectiveness)
• Chứa ít lỗi tiềm tàng • Giá thành không vượt quá giá ước lượng
ban đầu • Dễ vận hành, sử dụng • Tính an toàn và độ tin cậy cao
HUT, Falt. of IT Dept. of SE, 2001 SE-I.38
1.5.2 Hiệu suất xử lý cao
• Hiệu suất thời gian tốt (efficiency): – Độ phức tạp tính toán thấp (Time
complexity) – Thời gian quay vòng ngắn (Turn Around
Time: TAT) – Thời gian hồi đáp nhanh (Response time)
• Sử dụng tài nguyên hữu hiệu: CPU, RAM, HDD, Internet resources, . . .
HUT, Falt. of IT Dept. of SE, 2001 SE-I.39
1.5.3 Tính dễ hiểu
• Kiến trúc và cấu trúc thiết kế dễ hiểu • Dễ kiểm tra, kiểm thử, kiểm chứng • Dễ bảo trì • Có tài liệu (mô tả yêu cầu, điều kiện kiểm thử, vận hành, bảo trì, FAQ, . . .) với chất lượng cao
Tính dễ hiểu: chỉ tiêu ngày càng quan trọng
HUT, Falt. of IT Dept. of SE, 2001 SE-I.40
1.6 Các ứng dụng phần mềm
• Phần mềm hệ thống (System SW) • Phần mềm thời gian thực (Real-time SW) • Phần mềm nghiệp vụ (Business SW) • Phần mềm tính toán KH&KT (Eng.&Scie. SW) • Phần mềm nhúng (Embedded SW) • Phần mềm máy cá nhân (Personal computer SW) • Phần mềm trên Web (Web-based SW) • Phần mềm trí tuệ nhân tạo (AI SW)
HUT, Falt. of IT Dept. of SE, 2001 SE-I.41
Chương 2: Khủng hoảng phần mềm
(Software Crisis) 2.1 Khủng hoảng phần mềm là gì ? 2.2 Những vấn đề (khó khăn) trong sản xuất phần mềm
HUT, Falt. of IT Dept. of SE, 2001 SE-I.42
2.1 Khủng hoảng phần mềm là gì?
• 10/1968 tại Hội nghị của NATO các chuyên gia phần mềm đã đưa ra thuật ngữ “Khủng hoảng phần mềm” (Software crisis). Qua hàng chục năm, thuật ngữ này vẫn được dùng và ngày càng mang tính cấp bách
• Khủng hoảng là gì ? [Webster’s Dict.] – Điểm ngoặt trong tiến trình của bất kỳ cái gì; thời điểm,
giai đoạn hoặc biến cố quyết định hay chủ chốt – Điểm ngoặt trong quá trình diễn biến bệnh khi trở nên
rõ ràng bệnh nhân sẽ sống hay chết • Trong phần mềm: Day dứt kinh niên (chronic affliation, by
Prof. Tiechrow, Geneva, Arp. 1989)
HUT, Falt. of IT Dept. of SE, 2001 SE-I.43
Khủng hoảng phần mềm là gì? (tiếp) Là sự day dứt kinh niên (kéo dài theo thời gian hoặc thường tái diễn, liên tục không kết thúc) gặp phải trong phát triển phần mềm máy tính, như
• Phải làm thế nào với việc giảm chất lượng vì những lỗi tiềm tàng có trong phần mềm ?
• Phải xử lý ra sao khi bảo dưỡng phần mềm đã có ? • Phải giải quyết thế nào khi thiếu kỹ thuật viên phần mềm?
• Phải chế tác phần mềm ra sao khi có yêu cầu phát triển theo qui cách mới xuất hiện ?
• Phải xử lý ra sao khi sự cố phần mềm gây ra những vấn đề xã hội ?
HUT, Falt. of IT Dept. of SE, 2001 SE-I.44
Một số yếu tố • Phần mềm càng lớn sẽ kéo theo phức tạp hóa
và tăng chi phí phát triển • Đổi vai trò giá thành SW vs. HW • Công sức cho bảo trì càng tăng thì chi phí cho
Backlog càng lớn • Nhân lực chưa đáp ứng được nhu cầu phần mềm
• Những phiền hà của phần mềm gây ra những vấn đề xã hội
HUT, Falt. of IT Dept. of SE, 2001 SE-I.45
Những dự án lớn của NASA (National Aeronautics and Space Administration)
Tªn dù ¸n
Thêi ®iÓmph t triÓn
Tæng sèb- í c (triÖu)
GEMINI Gi÷a 1960 6
APPOLO(1 Bill. $) § Çu 1970 13
SPACESHUTTLE Cuèi 1970 45
HUT, Falt. of IT Dept. of SE, 2001 SE-I.46
So sánh chi phí cho Phần cứng và Phần mềm
% 100
80
60
40
20
0
-
-
-
-
+ 1955
+ 1970
+ 2000
+ 1985
Phần cứng Phát triển
Bảo trì
Phần mềm
HUT, Falt. of IT Dept. of SE, 2001 SE-I.47
So sánh chi phí cho các pha
3
35
78 7
67
X¸ c ®Þnh yªu cÇu 3%§ Æc t¶ 3%ThiÕt kÕ 5%LËp tr×nh 7%KiÓm thö m«®un 8%KiÓm thö tÝch hî p 7%B¶o tr× 67%
HUT, Falt. of IT Dept. of SE, 2001 SE-I.48
Backlog tại Nhật Bản năm 1985
15.5
24.7
32.5
18.4
9.4
D- í i 6 th¸ ng 15.5%
6 th¸ ng ®Õn 1 n¨ m 24.7%
Tõ 1 ®Õn 2 n¨ m 32.5%
Tõ 2 ®Õn 3 n¨ m 18.4%
Trªn 3 n¨ m 9.4%
HUT, Falt. of IT Dept. of SE, 2001 SE-I.49
Những vấn đề (khó khăn) trong
sản xuất phần mềm (1) Không có phương pháp mô tả rõ ràng định
nghĩa yêu cầu của người dùng (khách hàng), sau khi bàn giao sản phẩm dễ phát sinh những trục trặc (troubles)
(2) Với những phần mềm quy mô lớn, tư liệu đặc tả đã cố định thời gian dài, do vậy khó đáp ứng nhu cầu thay đổi của người dùng một cách kịp thời trong thời gian đó
HUT, Falt. of IT Dept. of SE, 2001 SE-I.50
Những vấn đề trong sản xuất phần mềm (tiếp)
(3) Nếu không có Phương pháp luận thiết kế nhất quán mà thiết kế theo cách riêng (của công ty, nhóm), thì sẽ dẫn đến suy giảm chất lượng phần mềm (do phụ thuộc quá nhiều vào con người)
(4) Nếu không có chuẩn về làm tư liệu quy trình sản xuất phần mềm, thì những đặc tả không rõ ràng sẽ làm giảm chất lượng phần mềm
HUT, Falt. of IT Dept. of SE, 2001 SE-I.51
Những vấn đề trong sản xuất phần mềm (tiếp)
(5) Nếu không kiểm thử tính đúng đắn của phần mềm ở từng giai đoạn mà chỉ kiểm ở giai đoạn cuối và phát hiện ra lỗi, thì thường bàn giao sản phẩm không đúng hạn
(6) Nếu coi trọng việc lập trình hơn khâu thiết kế thì thường dẫn đến làm giảm chất lượng phần mềm
(7) Nếu coi thường việc tái sử dụng phần mềm (software reuse), thì năng suất lao động sẽ giảm
HUT, Falt. of IT Dept. of SE, 2001 SE-I.52
Những vấn đề trong sản xuất phần mềm (tiếp)
(8) Phần lớn trong quy trình phát triển phần mềm có nhiều thao tác do con người thực hiện, do vậy năng suất lao động thường bị giảm
(9) Không chứng minh được tính đúng đắn của phần mềm, do vậy độ tin cậy của phần mềm sẽ giảm
(10) Chuẩn về một phần mềm tốt không thể đo được một cách định lượng, do vậy không thể đánh giá được một hệ thống đúng đắn hay không
HUT, Falt. of IT Dept. of SE, 2001 SE-I.53
Những vấn đề trong sản xuất phần mềm (tiếp)
(11) Khi đầu tư nhân lực lớn vào bảo trì sẽ làm giảm hiệu suất lao động của nhân viên
(12) Công việc bảo trì kéo dài làm giảm chất lượng của tư liệu và ảnh hưởng xấu đến những việc khác
HUT, Falt. of IT Dept. of SE, 2001 SE-I.54
Những vấn đề trong sản xuất phần mềm (tiếp)
(13) Quản lý dự án lỏng lẻo kéo theo quản lý lịch trình cũng không rõ ràng (14) Không có tiêu chuẩn để ước lượng nhân lực và dự toán sẽ làm kéo dài thời hạn và vượt kinh phí của dự án Đây là những vấn đề phản ánh các khía cạnh khủng hoảng phần mềm, hãy tìm cách nỗ lực vượt qua để tạo ra phần mềm tốt!
HUT, Falt. of IT Dept. of SE, 2001 SE-I.55
Chương 3 Công nghệ học Phần mềm
(Software Engineering) 3.1 Lịch sử tiến triển Công nghệ học phần mềm 3.2 Sự tiến triển của các phương pháp thiết kế
phần mềm 3.3 Định nghĩa Công nghệ học phần mềm 3.4 Vòng đời của phần mềm 3.5 Quy trình phát triển phần mềm
HUT, Falt. of IT Dept. of SE, 2001 SE-I.56
3.1 Lịch sử tiến triển của CNHPM
• Nửa đầu 1960: ít quan tâm đến phần mềm, chủ yếu tập trung nâng cao tính năng và độ tin cậy của phần cứng
• Giữa những năm 1960: Phát triển hệ điều hành như phần mềm lớn (IBM OS/360, EC OS). Xuất hiện nhu cầu về quy trình phát triển phần mềm lớn và quy trình gỡ lỗi, kiểm thử trong phạm vi giới hạn
HUT, Falt. of IT Dept. of SE, 2001 SE-I.57
Lịch sử tiến triển của CNHPM (tiếp)
• Năm 1968: Tại Tây Đức, Hội nghị khoa học của NATO đã đưa ra từ “Software Engineering”. Bắt đầu bàn luận về khủng khoảng phần mềm và xu hướng hình thành CNHPM như một chuyên môn riêng
• Nửa cuối 1960: IBM đưa ra chính sách phân biệt giá cả giữa phần cứng và phần mềm. Từ đó, ý thức về phần mềm ngày càng cao. Bắt đầu những nghiên cứu cơ bản về phương pháp luận lập trình
HUT, Falt. of IT Dept. of SE, 2001 SE-I.58
Lịch sử tiến triển của CNHPM (tiếp)
• Nửa đầu những năm 1970: Nhằm nâng cao chất lượng phần mềm, không chỉ có các nghiên cứu về lập trình, kiểm thử, mà có cả những nghiên cứu đảm bảo tính tin cậy trong quy trình sản xuất phần mềm. Kỹ thuật: lập trình cấu trúc hóa, lập trình môđun, thiết kế cấu trúc hóa, vv
• Giữa những năm 1970: Hội nghị quốc tế đầu tiên về CNHPM được tổ chức (1975): International Conference on SE (ICSE)
HUT, Falt. of IT Dept. of SE, 2001 SE-I.59
Lịch sử tiến triển của CNHPM (tiếp)
• Nửa sau những năm 1970: Quan tâm đến mọi pha trong quy trình phát triển phần mềm, nhưng tập trung chính ở những pha đầu. ICSE tổ chức lần 2, 3 và 4 vào 1976, 1978 và 1979 – Nhật Bản có “Kế hoạch phát triển kỹ thuật sản xuất phần mềm” từ năm 1981
– Cuộc “cách tân sản xuất phần mềm” đã bắt đầu trên phạm vi các nước công nghiệp
HUT, Falt. of IT Dept. of SE, 2001 SE-I.60
Lịch sử tiến triển của CNHPM (tiếp)
• Nửa đầu những năm 1980: Trình độ học vấn và ứng dụng CNHPM được nâng cao, các công nghệ được chuyển vào thực tế. Xuất hiện các sản phẩm phần mềm và các công cụ khác nhau làm tăng năng suất sản xuất phần mềm đáng kể – ICSE tổ chức lần 5 và 6 năm 1981 và 1982 với trên
1000 người tham dự mỗi năm – Nhật Bản sang “Kế hoạch phát triển các kỹ thuật bảo trì phần mềm” (1981-1985)
HUT, Falt. of IT Dept. of SE, 2001 SE-I.61
Lịch sử tiến triển của CNHPM (tiếp) • Nửa cuối những năm 1980 đến nay: Từ học vấn sang nghiệp vụ! Chất lượng phần mềm tập trung chủ yếu ở tính năng suất, độ tin cậy và tính bảo trì. Nghiên cứa hỗ trợ tự động hóa sản xuất phần mềm – Nhật Bản có “Kế hoạch hệ thống công nghiệp hóa sản xuất phần mềm”(SIGMA: Software Industrialized Generator & Maintenance Aids, 1985-1990)
– Nhiều trung tâm, viện nghiên cứu CNHPM ra đời. Các trường đưa vào giảng dạy SE
HUT, Falt. of IT Dept. of SE, 2001 SE-I.62
Hiện nay
• Công nghiệp hóa sản xuất phần mềm bằng cách đưa những kỹ thuật công nghệ học (Engineering techniques) thành cơ sở khoa học của CNHPM
• Thể chế hóa lý luận trong sản xuất phần mềm và ứng dụng những phương pháp luận một cách nhất quán
• Tăng cường nghiên cứu và tạo công cụ trợ giúp sản xuất phần mềm
HUT, Falt. of IT Dept. of SE, 2001 SE-I.63
3.2 Sự tiến triển của các phương pháp thiết kế phần mềm • Phương pháp luận trong CNHPM: bắt đầu từ những năm 1970
• Trong phát triển phần mềm: nâng cao năng suất, độ tin cậy, giá thành - tính năng (productivity, reliability, cost-performance)
• Tiến triển phương pháp thiết kế: Sơ khởi, Trưởng thành, Phát triển và Biến đổi
HUT, Falt. of IT Dept. of SE, 2001 SE-I.64
Sơ khởi: nửa đầu 1970
• Khái niệm về tính môđun, cụ thể hóa từng bước trong phương pháp luận thiết kế
• N. Wirth: Chi tiết hóa từng giai đoạn. Thiết kế trên xuống. Lập trình môđun
HUT, Falt. of IT Dept. of SE, 2001 SE-I.65
Trưởng thành: nửa cuối 1970 • Phương pháp luận về quy trình thiết kế phần mềm với phương pháp phân chia môđun và thiết kế trong từng môđun.
• L.L. Constantine, 1974: Thiết kế cấu trúc hóa (phân chia môđun);
• E.W. Dijkstra, 1972: Lập trình cấu trúc hóa (trong môđun) . Phương pháp M.A. Jackson (1975) và J.D. Warnier (1974)
• Trừu tượng hóa dữ liệu: B.H. Liskov (1974);D.L. Parnas (1972)
HUT, Falt. of IT Dept. of SE, 2001 SE-I.66
Phát triển: nửa đầu 1980
• Triển khai các công cụ hỗ trợ phát triển phần mềm dựa trên các phương pháp và kỹ thuật đưa ra những năm 1970
• Bộ khởi tạo chương trình (program generators: pre-compiler; graphics-input editors, etc.)
• Ngôn ngữ đối thoại đơn giản (4GL, DB SQL) • Hệ trợ giúp: Hệ trợ giúp kiểm thử; Hệ trợ giúp quản lý thư viện; Hệ trợ giúp tái sử dụng
HUT, Falt. of IT Dept. of SE, 2001 SE-I.67
Biến đổi: nửa cuối 1980 đến nay
• Đưa ra các môi trường mới về phát triển phần mềm. Triển khai mới về kết hợp giữa CNHPM và CNH Tri thức (Knowledge Engineering)
• Triển khai những môi trường bậc cao về phát triển phần mềm; Tự động hóa sản xuất phần mềm; Chế phần mềm theo kỹ thuật chế thử (Prototyping); Lập trình hướng đối tượng - OOP; Hướng thành phần; Hỗ trợ phát triển phần mềm từ các hệ chuyên gia, vv
HUT, Falt. of IT Dept. of SE, 2001 SE-I.68
Hình thái sản xuất Phần mềm Đưa ra các kỹ thuật, phương pháp luận
ứng dụng thực tế vào từng quy trình
Cải biên, biến đổi vào từng sản phẩm và công cụ phần mềm (máy tính hóa từng phần)
Tổng hợp, hệ thống hóa cho từng loại công cụ (Máy tính hóa toàn bộ quy trình sản xuất phần mềm)
Hướng tới sản xuất phần mềm tự động
HUT, Falt. of IT Dept. of SE, 2001 SE-I.69
3.3 Định nghĩa Công nghệ học phần mềm • Bauer [1969]: CNHPM là việc thiết lập và sử dụng các nguyên tắc công nghệ học đúng đắn dùng để thu được phần mềm một cách kinh tế vừa tin cậy vừa làm việc hiệu quả trên các máy thực
• Parnas [1987]: CNHPM là việc xây dựng phần mềm nhiều phiên bản bởi nhiều người
• Ghezzi [1991]: CNHPM là một lĩnh vực của khoa học máy tính, liên quan đến xây dựng các hệ thống phần mềm vừa lớn vừa phức tạp bởi một hay một số nhóm kỹ sư
HUT, Falt. of IT Dept. of SE, 2001 SE-I.70
Định nghĩa CNHPM (tiếp) • IEEE [1993]: CNHPM 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)
• Pressman [1995]: CNHPM là bộ môn tích hợp cả quy trình, các phương pháp, các công cụ để phát triển phần mềm máy tính
HUT, Falt. of IT Dept. of SE, 2001 SE-I.71
Định nghĩa CNHPM (tiếp) • Sommerville [1995]: CNHPM là lĩnh vực liên
quan đến lý thuyết, phương pháp và công cụ dùng cho phát triển phần mềm
• K. Kawamura [1995]: CNHPM là lĩnh vực học vấn về các kỹ thuật, phương pháp luận công nghệ học (lý luận và kỹ thuật được hiện thực hóa trên những nguyên tắc, nguyên lý nào đó) trong toàn bộ quy trình phát triển phần mềm nhằm nâng cao cả chất và lượng của sản xuất phần mềm
HUT, Falt. of IT Dept. of SE, 2001 SE-I.72
Định nghĩa CNHPM (tiếp) Công nghệ học phần mềm là lĩnh vực khoa học về các phương pháp luận, kỹ thuật và công cụ tích hợp trong quy trình sản xuất và vận hành phần mềm nhằm tạo ra phần mềm với những chất lượng mong muốn [Software Engineering is a scientìic field to deal with methodologies, techniques and tools integrated in software production-maintenance process to obtain software with desired qualities]
HUT, Falt. of IT Dept. of SE, 2001 SE-I.73
Công nghệ học trong CNHPM ? (1) Như các ngành công nghệ học khác, CNHPM
cũng lấy các phương pháp khoa học làm cơ sở (2) Các kỹ thuật về thiết kế, chế tạo, kiểm thử và bảo
trì phần mềm đã được hệ thống hóa hóa thành phương pháp luận và hình thành nên CNHPM
(3) Toàn bộ quy trình quản lý phát triển phần mềm gắn với khái niệm vòng đời phần mềm, được mô hình hóa với những kỹ thuật và phương pháp luận trở thành các chủ đề khác nhau trong CNHPM
HUT, Falt. of IT Dept. of SE, 2001 SE-I.74
Công nghệ học trong CNHPM ? (tiếp) (4) Trong vòng đời phần mềm không chỉ có chế tạo
mà bao gồm cả thiết kế, vận hành và bảo dưỡng (tính quan trọng của thiết kế và bảo dưỡng)
(5) Trong khái niệm phần mềm, không chỉ có chương trình mà cả tư liệu về phần mềm
(6) Cách tiếp cận công nghệ học (khái niệm công nghiệp hóa) thể hiện ở chỗ nhằm nâng cao năng suất (tính năng suất) và độ tin cậy của phần mềm, đồng thời giảm chi phí giá thành
HUT, Falt. of IT Dept. of SE, 2001 SE-I.75
3.4 Vòng đời phần mềm (Software life-cycle)
• Vòng đời phần mềm là thời kỳ tính từ khi phần mềm được sinh (tạo) ra cho đến khi chết đi (từ lúc hình thành đáp ứng yêu cầu, vận hành, bảo dưỡng cho đến khi loại bỏ không đâu dùng)
• Quy trình phần mềm (vòng đời phần mềm) được phân chia thành các pha chính: phân tích, thiết kế, chế tạo, kiểm thử, bảo trì. Biểu diễn các pha có khác nhau theo từng người
HUT, Falt. of IT Dept. of SE, 2001 SE-I.76
Mô hình vòng đời phần mềm của Boehm Xác định yêu cầu hệ thống Kiểm chứng
Xác định yêu cầu phần mềm Kiểm chứng
Thiết kế căn bản
Kiểm chứng
Thiết kế chi tiết
Kiểm chứng
Lập trình
Gỡ lỗi
Kiểm thử
Chạy thử
Vận hành Bảo trì
Kiểm chứng lại
HUT, Falt. of IT Dept. of SE, 2001 SE-I.77
Suy nghĩ mới về vòng đời phần mềm
(1) Pha xác định yêu cầu và thiết kế có vai trò quyết định đến chất lượng phần mềm, chiếm phần lớn công sức so với lập trình, kiểm thử và chuyển giao phần mềm
(2) Pha cụ thể hóa cấu trúc phần mềm phụ thuộc nhiều vào suy nghĩ trên xuống (top-down) và trừu tượng hóa, cũng như chi tiết hóa
(3) Pha thiết kế, chế tạo thì theo trên xuống, pha kiểm thử thì dưới lên (bottom-up)
HUT, Falt. of IT Dept. of SE, 2001 SE-I.78
Suy nghĩ mới về vòng đời phần mềm
(4) Trước khi chuyển sang pha kế tiếp phải đảm bảo pha hiện nay đã được kiểm thử không còn lỗi
(5) Cần có cơ chế kiểm tra chất lượng, xét duyệt giữa các pha nhằm đảm bảo không gây lỗi cho pha sau
(6) Tư liệu của mỗi pha không chỉ dùng cho pha sau, mà chính là đối tượng quan trọng cho kiểm tra và đảm bảo chất lượng của từng quy trình và của chính phần mềm
HUT, Falt. of IT Dept. of SE, 2001 SE-I.79
Suy nghĩ mới về vòng đời phần mềm
(7) Cần chuẩn hóa mẫu biểu, cách ghi chép tạo tư liệu cho từng pha, nhằm đảm bảo chất lượng phần mềm
(8) Thao tác bảo trì phần mềm là việc xử lý quay vòng trở lại các pha trong vòng đời phần mềm nhằm biến đổi, sửa chữa, nâng cấp phần mềm
HUT, Falt. of IT Dept. of SE, 2001 SE-I.80
Các phương pháp luận và kỹ thuật cho từng pha
Tªn pha Néi dung nghiÖp vô Ph- ¬ng ph p, küthuËt
X¸c ®Þnhyªu cÇu
§ Æc t¶ yªu cÇu ng- êi dï ngX¸c ®Þnh yªu cÇu phÇn mÒm
Ph©n tÝch cÊu tróchãa
ThiÕt kÕhÖ thèng
ThiÕt kÕ c¬ b¶n phÇn mÒmThiÕt kÕ cÊu tróc ngoµi cña phÇnmÒm
ThiÕt kÕ cÊu tróc hãa
ThiÕt kÕch- ¬ngtr×nh
Lµ thiÕt kÕ chi tiÕt: ThiÕt kÕ cÊutróc bªn trong cña phÇn mÒm (®¬nvÞ ch- ¬ng tr×nh hoÆc m«®un)
LËp tr×nh cÊu trócPh- ¬ng ph p JacksonPh- ¬ng ph pWarnier
LËp tr×nh M· hãa bëi ng«n ng÷ lËp tr×nh M· hãa cÊu tróc hãa§ ¶m b¶ochÊt l- î ng
KiÓm tra chÊt l- î ng phÇn mÒm ®·ph t triÓn
Ph- ¬ng ph p kiÓmthö ch- ¬ng tr×nh
VËn hµnhB¶o tr×
Sö dông, vËn hµnh phÇn mÒm ®·ph t triÓn. BiÕn ®æi, ®iÒu chØnhphÇn mÒm
Ch- a cô thÓ
HUT, Falt. of IT Dept. of SE, 2001 SE-I.81
3.5 Quy trình phát triển phần mềm Common process framework - Khung quy trình chung
Umbrella activities
Framework activities - Hoạt động khung
Task sets - Tập tác vụ Tasks - Tác vụ
Milestones, deliverables
SQA points - Điểm KTCL
HUT, Falt. of IT Dept. of SE, 2001 SE-I.82
3.5.1 Capability Maturity Model (CMM) by SEI: Mô hình thuần thục khả năng
• Level 1: Initial (Khởi đầu). Few processes are defined. Success depends on individual effort
• Level 2: Repeatable (Lặp lại). Basic project management processes. Repeat earlier succeses on projects with similar applications
• Level 3: Defined (Xác định). Use a documented and approved version of the organization’s process for developing and supporting software
HUT, Falt. of IT Dept. of SE, 2001 SE-I.83
CMM (cont.)
• Level 4: Managed (Quản trị). Both SW process and products are quantitatively understood and controlled using detailed measures
• Level 5: Optimizing (Tối ưu). Continuous process improvement is enabled by quantitative feedback from the process and from testing innovative ideas and technologies
18 key process areas (KPAs) for CMM
HUT, Falt. of IT Dept. of SE, 2001 SE-I.84
18 KPAs of CMM LEVEL 2: Repeatable 1. SW configuration management 2. SW quality assurance 3. SW subcontract management 4. SW project tracking and oversight 5. SW project planning 6. Requirements management
7. Peer reviews 8. Intergroup coordination 9. SW product engineering 10. IntegratedSW management 11. Training program 12. Organization process definition 13. Organization process focus
LEVEL 3: Defined
14. SW quality Management 15. Quantitative process management
LEVEL 4: Managed LEVEL 5: Optimizing
16. Process change management 17. Technology change management 18. Defect prevention
HUT, Falt. of IT Dept. of SE, 2001 SE-I.85
3.5.2 Mô hình tuyến tính
Phân tích Thiết kế Lập trình Kiểm thử
Công nghệ học Hệ thống / Thông tin
Điển hình là mô hình vòng đời cổ điển (mô hình thác nước) Classic life cycle / waterfall model: là mô hình hay đựoc dùng nhất
HUT, Falt. of IT Dept. of SE, 2001 SE-I.86
Mô hình tuyến tính
• Công nghệ học Hệ thống / Thông tin và mô hình hóa (System / Information engineering and modeling): thiết lập các yêu cầu, ánh xạ một số tập con các yêu cầu sang phần mềm trong quá trình tương tác giữa phần cứng, người và CSDL
• Phân tích yêu cầu (Requirements analysis): hiểu lĩnh vực thông tin, chức năng, hành vi, tính năng và giao diện của phần mềm sẽ phát triển. Cần phải tạo tư liệu và bàn thảo với khách hàng, người dùng
HUT, Falt. of IT Dept. of SE, 2001 SE-I.87
Mô hình tuyến tính
• Thiết kế (Design): là quá trình nhiều bước với 4 thuộc tính khác nhau của một chương trình: cấu trúc dữ liệu, kiến trúc phần mềm, biểu diễn giao diện và chi tiết thủ tục (thuật toán). Cần tư liệu hóa và là một phần quan trọng của cấu hình phần mềm
• Tạo mã / lập trình (Code generation / programming): Chuyển thiết kế thành chương trình máy tính bởi ngôn ngữ nào đó. Nếu thiết kế đã được chi tiết hóa thì lập trình có thể chỉ thuần túy cơ học
HUT, Falt. of IT Dept. of SE, 2001 SE-I.88
Mô hình tuyến tính
• Kiểm thử (Testing): Kiểm tra các chương trình và môđun cả về lôgic bên trong và chức năng bên ngoài, nhằm phát hiện ra lỗi và đảm bảo với đầu vào xác định thì cho kết quả mong muốn
• Hỗ trợ / Bảo trì (Support / Maintenance): Đáp ứng những thay đổi, nâng cấp phần mềm đã phát triển do sự thay đổi của môi trường, nhu cầu
HUT, Falt. of IT Dept. of SE, 2001 SE-I.89
Điểm yếu của Mô hình tuyến tính
• 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 (như mô hình của Boehm)
• Khách hàng ít khi tuyên bố rõ ràng khi nào xong hết các yêu cầu
• Khách hàng phải có lòng kiên nhẫn chờ đợi thời gian nhất định mới có sản phẩm. Nếu phát hiện ra lỗi nặng thì là một thảm họa!
HUT, Falt. of IT Dept. of SE, 2001 SE-I.90
3.5.3 Mô hình chế thử (Prototyping model)
Nghe Khách trình bày
Tạo / sửa bản mẫu
Khách kiểm tra bản mẫu
HUT, Falt. of IT Dept. of SE, 2001 SE-I.91
Mô hình chế thử: Khi nào ?
• Khi mới rõ mục đích chung chung của phần mềm, chưa rõ chi tiết đầu vào hay xử lý ra sao hoặc chưa rõ yêu cầu đầu ra
• Dùng như “Hệ sơ khai” để thu thập yêu cầu người dùng qua các thiết kế nhanh
• Các giải thuật, kỹ thuật dùng làm bản mẫu có thể chưa nhanh, chưa tốt, miễn là có mẫu để thảo luận gợi yêu cầu của người dùng
HUT, Falt. of IT Dept. of SE, 2001 SE-I.92
3.5.4 Mô hình phát triển ứng dụng nhanh (Rapid Application Development:
RAD) • Là quy trình phát triển phần mềm gia tăng, tăng dần từng bước (Incrimental software development) với mỗi chu trình phát triển rất ngắn (60-90 ngày)
• Xây dựng dựa trên hướng thành phần (Component-based construction) với khả năng tái sử dụng (reuse)
• Gồm một số nhóm (teams), mỗi nhóm làm 1 RAD theo các pha: Mô hình nghiệp vụ, Mô hình dữ liệu, Mô hình xử lý, Tạo ứng dụng, Kiểm thử và đánh giá (Business, Data, Process, Appl. Generation, Test)
HUT, Falt. of IT Dept. of SE, 2001 SE-I.93
Mô hình phát
triển ứng dụng
nhanh Business Modeling
Data Modeling
Process Modeling
Application Generation
Testing & Turnover
60 - 90 days
Business Modeling
Data Modeling
Process Modeling
Application Generation
Testing & Turnover
Business Modeling
Data Modeling
Process Modeling
Application Generation
Testing & Turnover
Team #1
Team #2
Team #3
HUT, Falt. of IT Dept. of SE, 2001 SE-I.94
RAD: Business modeling
Luồng thông tin được mô hình hóa để trả lời các câu hỏi:
– Thông tin nào điều khiển xử lý nghiệp vụ ? – Thông tin gì được sinh ra? – Ai sinh ra nó ? – Thông tin đi đến đâu ? – Ai xử lý chúng ?
HUT, Falt. of IT Dept. of SE, 2001 SE-I.95
RAD: Data and Process modeling
• Data modeling: các đối tượng dữ liệu cần để hỗ trợ nghiệp vụ (business). Định nghĩa các thuộc tính của từng đối tượng và xác lập quan hệ giữa các đối tượng
• Process modeling: Các đối tượng dữ liệu được chuyển sang luồng thông tin thực hiện chức năng nghiệp vụ. Tạo mô tả xử lý đễ cập nhật (thêm, sửa, xóa, khôi phục) từng đối tượng dữ liệu
HUT, Falt. of IT Dept. of SE, 2001 SE-I.96
RAD: Appl. Generation and Testing
• Application Generation: Dùng các kỹ thuật thế hệ 4 để tạo phần mềm từ các thành phần có sẵn hoặc tạo ra các thành phần có thể tái dụng lại sau này. Dùng các công cụ tự động để xây dựng phần mềm
• Testing and Turnover: Kiểm thử các thành phần mới và kiểm chứng mọi giao diện (các thành phần cũ đã được kiểm thử và dùng lại)
HUT, Falt. of IT Dept. of SE, 2001 SE-I.97
RAD: Hạn chế ? • Cần nguồn nhân lực dồi dào để tạo các nhóm cho
các chức năng chính • Yêu cầu hai bên giao kèo trong thời gian ngắn phải có phần mềm hoàn chỉnh, thiếu trách nhiệm của một bên dễ làm dự án đổ vỡ
• RAD không phải tốt cho mọi ứng dụng, nhất là với ứng dụng không thể môđun hóa hoặc đòi hỏi tính năng cao
• Mạo hiểm kỹ thuật cao thì không nên dùng RAD
HUT, Falt. of IT Dept. of SE, 2001 SE-I.98
3.5.5 Các mô hình tiến hóa: gia tăng, xoắn ốc, xoắn WINWIN, ...
• Phần lớn các hệ phần mềm phức tạp đều tiến hóa theo thời gian: môi trường thay đổi, yêu cầu phát sinh thêm, hoàn thiện thêm chức năng, tính năng
• Các mô hình tiến hóa (evolutionary models) có tính lặp lại. Kỹ sư phần mềm tạo ra các phiên bản (versions) ngày càng hoàn thiện hơn, phức tạp hơn
• Các mô hình: incremental, spiral, WINWIN spiral, concurrent development model
HUT, Falt. of IT Dept. of SE, 2001 SE-I.99
Mô hình gia tăng (The incremental model)
• Kết hợp mô hình tuần tự và ý tưởng lặp lại của chế bản mẫu
• Sản phẩm lõi với những yêu cầu cơ bản nhất của hệ thống được phát triển
• Các chức năng với những yêu cầu khác được phát triển thêm sau (gia tăng)
• Lặp lại quy trình để hoàn thiện dần
HUT, Falt. of IT Dept. of SE, 2001 SE-I.100
Mô hình gia tăng
Ph©n tÝch ThiÕt kÕ LËp tr×nh KiÓm thö
System/info. Engineering
Calendar time
Ph©n tÝch ThiÕt kÕ LËp tr×nh KiÓm thö
Ph©n tÝch ThiÕt kÕ LËp tr×nh KiÓm thö
Ph©n tÝch ThiÕt kÕ LËp tr×nh KiÓm thö
Gia tăng 1
Gia tăng 2
Gia tăng 3
Gia tăng 4
Xuất xưởng 2
Xuất xưởng 1
Xuất xưởng 3
XX 4
HUT, Falt. of IT Dept. of SE, 2001 SE-I.101
Mô hình xoắn ốc (spiral)
Giao tiếp khách hàng
Lập kế hoạch Phân tích rủi ro
Kỹ nghệ
Xây dựng & Xuất xưởng
Khách hàng đánh giá
Bảo trì
Nâng cấp
Làm mới
Khái niệm
HUT, Falt. of IT Dept. of SE, 2001 SE-I.102
Mô hình xoắn ốc (tiếp)
• Giao tiếp khách hàng: giữa người phát triển và khách hàng để tìm hiểu yêu cầu, ý kiến
• Lập kế hoạch: Xác lập tài nguyên, thời hạn và những thông tin khác
• Phân tích rủi ro: Xem xét mạo hiểm kỹ thuật và mạo hiểm quản lý
• Kỹ nghệ: Xây dựng một hay một số biểu diễn của ứng dụng
HUT, Falt. of IT Dept. of SE, 2001 SE-I.103
Mô hình xoắn ốc (tiếp)
• Xây dựng và xuất xưởng: xây dựng, kiểm thử, cài đặt và cung cấp hỗ trợ người dùng (tư liệu, huấn luyện, . . .)
• Đánh giá của khách hàng: Nhận các phản hồi của người sử dụng về biểu diễn phần mềm trong giai đoạn kỹ nghệ và cài đặt
HUT, Falt. of IT Dept. of SE, 2001 SE-I.104
Mô hình xoắn ốc: Mạnh và yếu?
• Tốt cho các hệ phần mềm quy mô lớn • Dễ kiểm soát các mạo hiểm ở từng mức tiến
hóa • Khó thuyết phục khách hàng là phương
pháp tiến hóa xoắn ốc có thể kiểm soát được
• Chưa được dùng rộng rãi như các mô hình tuyến tính hoặc chế thử
HUT, Falt. of IT Dept. of SE, 2001 SE-I.105
Mô hình xoắn ốc WINWIN
• Nhằm thỏa hiệp giữa người phát triển và khách hàng, cả hai cùng “Thắng” (win-win) – Khách thì có phần mềm thỏa mãn yêu cầu chính – Người phát triển thì có kinh phí thỏa đáng và thời
gian hợp lý
• Các hoạt động chính trong xác định hệ thống: – Xác định cổ đông (stakeholders) – Xác định điều kiện thắng của cổ đông – Thỏa hiệp điều kiện thắng của các bên liên quan
HUT, Falt. of IT Dept. of SE, 2001 SE-I.106
Mô hình xoắn ốc WINWIN
1. Xác định mức tiếp của cổ đông
2. Xác định điều kiện thắng của cổ đông
3a. Hòa hợp điều kiện thắng 3b. Thiết lập mục tiêu mức tiếp và các ràng buộc, dự kiến
4. Đánh giá tiến trình và dự kiến sản phẩm, giải quyết rủi ro
5. Xác định mức tiếp của sản phâm và quy trình, kể cả phân chia nhỏ
7. Xét duyệt và đánh giá 6. Kiểm định sản phẩm và quy trình
HUT, Falt. of IT Dept. of SE, 2001 SE-I.107
Mô hình phát triển đồng thời (The concurrent development model)
• Xác định mạng lưới những hoạt động đồng thời (Network of concurrent activities)
• Các sự kiện (events) xuất hiện theo điều kiện vận động trạng thái trong từng hoạt động
• Dùng cho mọi loại ứng dụng và cho hình ảnh khá chính xác về trạng thái hiện trạng của dự án
• Thường dùng trong phát triển các ứng dụng khách/chủ (client/server applications): system and componets are developed concurrently
HUT, Falt. of IT Dept. of SE, 2001 SE-I.108
3.5.6 Mô hình theo thành phần (Component-based model)
• Gắn với những công nghệ hướng đối tượng (Object-oriented technologies) qua việc tạo các lớp (classes) có chứa cả dữ liệu và giải thuật xử lý dữ liệu
• Có nhiều tương đồng với mô hình xoắn ốc • Với ưu điểm tái sử dụng các thành phần qua Thư viện / kho các lớp: tiết kiệm 70% thời gian, 80% giá thành, chỉ số sản xuất 26.2/16.9
• Với UML như chuẩn công nghiệp đang triển khai
HUT, Falt. of IT Dept. of SE, 2001 SE-I.109
Mô hình theo thành phần
Giao tiếp khách hàng
Lập kế hoạch Phân tích rủi ro
Kỹ nghệ Xây dựng & Xuất xưởng
Khách hàng đánh giá
Xác định thành phần ứng viên
Tìm thành phần từ thư viện
Lấy thành phần nếu có
Xây dựng thành phần nếu kh.có
Đặt thành phần vào thư viện
Xây dựng bước lặp thứ n của hệ thống
HUT, Falt. of IT Dept. of SE, 2001 SE-I.110
3.5.7 Mô hình hình thức (Formal model)
• Còn gọi là CNHPM phòng sạch (Cleanroom SE) • Tập hợp các công cụ nhằm đặc tả toán học phần mềm máy tính từ khâu định nghĩa, phát triển đến kiểm chứng
• Giúp kỹ sư phần mềm phát hiện và sửa các lỗi khó
• Thường dùng trong phát triển SW cần độ an toàn rất cao (y tế, hàng không, . . .)
HUT, Falt. of IT Dept. of SE, 2001 SE-I.111
Mô hình hình thức: Điểm yếu ?
• Cần nhiều thời gian và công sức để phát triển
• Phí đào tạo cao vì ít người có nền căn bản cho áp dụng mô hình hình thức
• Khó sử dụng rộng rãi vì cần kiến thức toán và kỹ năng của khách hàng
HUT, Falt. of IT Dept. of SE, 2001 SE-I.112
3.5.8 Các kỹ thuật thế hệ 4 (Fourth generation techniques)
• Tập hợp các công cụ cho phép xác định đặc tính phần mềm ở mức cao, sau đó sinh tự động mã nguồn dựa theo đặc tả đó
• Các công cụ 4GT điển hình: ngôn ngữ phi thủ tục cho truy vấn CSDL; tạo báo cáo; xử lý dữ liệu; tương tác màn hình; tạo mã nguồn; khả năng đồ họa bậc cao; khả năng bảng tính; khả năng giao diện Web; vv
HUT, Falt. of IT Dept. of SE, 2001 SE-I.113
4GT: How ? • Từ thu thập yêu cầu cho đến sản phẩm: đối thoại giữa khách và người phát triển là quan trọng
• Không nên bỏ qua khâu thiết kế. 4GT chỉ áp dụng để triển khai thiết kế qua 4GL
• Mạnh: giảm thời gian phát triển và tăng năng suất • Yếu: 4GT khó dùng hơn ngôn ngữ lập trình, mã
khó tối ưu và khó bảo trì cho hệ thống lớn ⇒ cần kỹ năng của kỹ sư phần mềm
• Tương lai: 4GT với mô hình theo thành phần
HUT, Falt. of IT Dept. of SE, 2001 SE-I.114
3.5.9 Sản phẩm và quy trình (Product and process)
• Quy trình yếu thì sản phẩm khó mà tốt, song không nên coi trọng quá mức vào quy trình hoặc quá mức vào sản phẩm
• Sản phẩm và quy trình cần được coi trọng như nhau
HUT, Falt. of IT Dept. of SE, 2001 SE-I.115
Bài tập Phần I và Đồ án I • Xem lại các khái niệm, mô hình của phần mềm và
CNHPM • Đồ án môn học I (cho 13 nhóm, nạp báo cáo, tư liệu tìm được trên Web và thư viện): – Tìm hiểu và viết báo cáo, trình bày về mô hình
phát triển phần mềm (10 mô hình / 10 nhóm) – Chuẩn ISO 9001 cho SE – Chuẩn CMM (www.sei.com) – Các kỹ thuật lập trình (cấu trúc, mô đun, . . .)
HUT, Falt. of IT Dept. of SE, 2001 SE-II.1
Phần II
Phương pháp Quản lý Dự án CNTT
Chương 4
Quản lý dự án CNTT Bộ môn Công nghệ Phần mềm
Khoa Công nghệ Thông tin Đại học Bách Khoa Hà Nội
HUT, Falt. of IT Dept. of SE, 2001 SE-II.2
Nội dung trình bày
Tổng quan Lập kế hoạch quản lý Tổ chức dự án Quản lý rủi ro Phát triển nhóm Quản lý chất lượng Lập kế hoạch làm việc chi tiết Kiểm soát và lập báo cáo dự án Quản lý vấn đề và kiểm soát thay đổi Quản lý cấu hình Hoàn tất dự án
I. Tổng quan
Phương pháp Quản lý Dự án CNTT
HUT, Falt. of IT Dept. of SE, 2001 SE-II.4
Mục tiêu
Để hiểu về
Khái niệm về dự án và quản lý dự án
Tại sao các dự án lại thất bại
Các dự án CNTT có gì đặc biệt
HUT, Falt. of IT Dept. of SE, 2001 SE-II.5
Các định nghĩa về quản lý dự án
Một dự án:
♦là riêng biệt, độc lập ♦có điểm bắt đầu và điểm kết thúc ♦có sản phẩm cụ thể cuối cùng ♦là duy nhất, hoặc về sản phẩm hoặc về môi trường của nó
HUT, Falt. of IT Dept. of SE, 2001 SE-II.6
Tại sao các dự án lại thất bại? hay điều gì khiến một dự án thành công?
Quản lý dự án là để đưa ra một sản phẩm cuối cùng: • đúng hạn • trong phạm vi ngân sách hay nguồn tài chính cho
phép • phù hợp theo các đặc tả • với một mức độ chất lượng để phục vụ các nhu cầu
kinh doanh và đáp ứng các tiêu chuẩn chuyên môn và kỳ vọng của công tác quản lý
HUT, Falt. of IT Dept. of SE, 2001 SE-II.7
Định nghĩa về dự án bị thất bại Một dự án mà:
Không đạt được các mục tiêu của dự án, và/hoặc
Bị vượt quá ngân sách ít nhất 30%
Không rõ các mục tiêu: 18%
Không quen thuộc với phạm vi và sự phức tạp của dự án: 17%
thiếu thông tin: 21% quản lý dự án không tốt: 32%
lý do khác: 12%
Tại sao dự án thất bại ?
HUT, Falt. of IT Dept. of SE, 2001 SE-II.8
Những nguyên nhân thất bại
Do nhà cung cấp phần cứng/phần mềm kém
Nhân viên kinh doanh cao cấp trong nhóm làm việc không hiệu quả
Quản lý dự án tồi
Công nghệ là quá mới đối với tổ chức
Ước tính và lập kế hoạch tồi
Các mục tiêu của dự án không được nêu ra đầy đủ
0 10 20 30 40 50 60 % đáp ứng
số liệu 1994
HUT, Falt. of IT Dept. of SE, 2001 SE-II.9
0 10 20 30 40 50 60 70 80 90
Để tránh thất bại
Cải tổ việc quản lý dự án
Nghiên cứu khả thi
Tăng số thành viên tham gia
Tăng các phương sách từ bên ngoài
Không phải những lý do trên
%
Đáp ứng
HUT, Falt. of IT Dept. of SE, 2001 SE-II.10
Các hoạt động dự án
Nguồn
Các đầu vào khác
các yêu cầu Các kết quả bàn giao của dự án
Các đầu ra khác
Quản lý Dự án
Những yêu cầu của người quản lý
.....và quản lý dự án không phải là thực hiện dự án!
Thực hiện dự án không có nghĩa là Quản trị dự án!
HUT, Falt. of IT Dept. of SE, 2001 SE-II.11
Các thuộc tính đặc trưng của dự án IT Các kết quả bàn giao có thể là ít hữu hình và ít quen
thuộc hơn so với các loại dự án khác Phạm vi có thể khó kiểm soát Đội dự án thường có những kỹ năng, kinh nghiệm, thái
độ và kỳ vọng trái ngược nhau Dự án có thể bị căng thẳng để đạt được các mục tiêu
kinh doanh Dự án có thể được kết nối với những sự thay đổi quan
trọng về tổ chức Các yêu cầu, phạm vi, và lợi nhuận chính xác có thể rất
khó xác định Sự thay đổi nhanh chóng về công nghệ có thể làm cho
nền tảng của dự án trở nên lỗi thời
HUT, Falt. of IT Dept. of SE, 2001 SE-II.12
Cấu trúc Phương pháp QLDA
qu¶n lý ngêi thùc hiÖn hîp ®ång phô
qu¶n lý c¸n bé dù ¸n
qu¶n lý sù thay ®èi vÒ tæ chøc
qu¶n lý rñi ro
Qu¶n l ý chÊt lîng
qu¶n lý c¸c vÊn ®Ò vµ kiÓm so¸t sù thay dæi
Qu¶n lý cÊu h×nh
§Þnh nghÜa dù ¸n
LËp KÕ ho¹ch
dù ¸n
Qu¶n lý vµ kiÓm so¸t dù ¸n
KÕt thóc
dù ¸n
HUT, Falt. of IT Dept. of SE, 2001 SE-II.13
10 quy tắc vàng Quản lý dự án thành công chính là vấn đề về con người
♦ nhưng không được quên quản trị Khám phá các nguồn hỗ trợ và chống đỡ Sự hiện diện có thể là dối trá - xem xét lịch trình ẩn đằng sau Phải hiểu rằng những con người khác nhau thì có những cách nhìn khác
nhau ♦ hãy đặt mình vào địa vị của họ
Thiết lập kế hoạch của bạn sao cho có thể chỉnh sửa dễ dàng Đối mặt với từng sự kiện như là nó đã có từ trước Sử dụng quản trị để hỗ trợ cho các mục đích của dự án Thời gian mục tiêu đối với từng nhiệm vụ không được giống như đã nêu
trong kế hoạch Đọc lại phạm vi và các mục tiêu của dự án mỗi tuần 1 lần Không ngạc nhiên!
II. Lập kế hoạch quản lý
Quản lý dự án CNTT
HUT, Falt. of IT Dept. of SE, 2001 SE-II.15
Các mục tiêu
Sau khi kết thúc phần này bạn sẽ: Hiểu được sự cần thiết của việc lập kế hoạch và
các bước của việc lập kế hoạch quản lý
Có thể lập ra một kế hoạch quản lý toàn diện ở một mức độ chi tiết hợp lý đối với dự án và đây chính là bước mở đầu của dự án
Có thể đưa ra cho khách hàng về sự cần thiết của việc lập kế hoạch quản lý
HUT, Falt. of IT Dept. of SE, 2001 SE-II.16
Lập kế hoạch quản lý Xác định ranh giới của dự án
♦ đội lập kế hoạch, văn bản/thông tin hiện có Xây dựng các lựa chọn tiếp cận dự án
♦ chiến lược thực hiện và các phương pháp luận tổ chức dự án
Xây dựng các ước tính ban đầu Xây dựng cơ sở hạ tầng nguồn
♦ môi trường làm việc Xây dựng cơ sở hạ tầng của dự án
♦ quản lý cấu hình, chất lượng, rủi ro, sự kiện, sự thay đổi, kiểm soát dự án, lập báo cáo, và lập kế hoạch
Lập thành văn bản về kế hoạch quản lý
HUT, Falt. of IT Dept. of SE, 2001 SE-II.17
Các vai trò và trách nhiệm của dự án
Ban điều hành Chiến lược kinh doanh Không Không Ban chỉ đạo điều hành dự án phê chuẩn từ lúc bắt đầu dự án Nhà tài trợ d/a luôn sẵn sàng đầu vào về phạm vi, từ lúc bắt đầu d/a hỗ trợ dự án mục tiêu, lợi ích Giám đốc dự án quản lý chiến xem xét và từ lúc bắt đầu d/a dự án phê chuẩn Quản lý dự án quản lý hoạt động chịu trách nhiệm Trong thời gian dự án về kết quả thực hiện dự án Nhóm trưởng dự án chịu trách nhiệm hỗ trợ người trong suốt thời gian về nhiệm vụ dự án quản lý dự án lập kế hoạch quản lý Cán bộ dự án hoàn thành nhiệm vụ None trong suốt thời gian hoạt động dự án
Vai trò Trách nhiệm Vai trò trong viẹc lập kế hoạch quản lý
thời gian thực hiện
HUT, Falt. of IT Dept. of SE, 2001 SE-II.18
Xây dựng & Thông qua kế hoạch quản lý
Các lợi ích khi lập kế hoạch quản lý
Khởi đầu sai lệch
Kh«ng ®¸p øng ®îc sù mong ®îi cña nhµ tµi trî vµ/hoÆc c¸c môc tiªu
Bị nhầm lẫn
Thông tin nghèo nàn
§¸p øng c¸c môc tiªu cña nhµ tµi trî G©y dùng lßng tin cña ®èi t¸c
ThiÕt lËp híng lµm viÖc chung
Bao qu¸t ®îc c¸c th¸ch thøc
Më ra c¸c kªnh th«ng tin liªn l¹c
B¾t ®Çu dù ¸n víi mét ph¬ng thøc cã hÖ thèng
những rủi ro gặp phải khi không lập kế hoạch quản lý
HUT, Falt. of IT Dept. of SE, 2001 SE-II.19
C¸c môc tiªu
§éi dù ¸n
Giá trị của các mục tiêu rõ ràng
Thiết lập sự mong đợi của nhà tài trợ dự án và các nhà đầu tư
Đưa ra điểm mục tiêu để hướng dẫn đội dự án
Cho phép bạn xác định thời điểm dự án kết thúc!
HUT, Falt. of IT Dept. of SE, 2001 SE-II.20
Các bước xác định phạm vi dự án
Xem xét lại các văn bản hiện có
Lập danh sách các văn bản/ thông tin chưa đầy đủ hay còn thiếu Tiến hành phỏng vấn và/hoặc hội thảo để thu thập các thông tin còn thiếu Phân loại các thông tin cụ thể liên quan đến các cam kết, lịch trình và các kết quả bàn giao Tiếp tục kết hợp chặt chẽ các chi tiết vào kế hoạch quản lý Đạt được thoả thuận
HUT, Falt. of IT Dept. of SE, 2001 SE-II.21
“Báo cáo phạm vi dự án” được xây dựng Các lợi ích của dự án được lập thành văn bản rõ ràng
Xác định được các kết quả chính và các tiêu thức để hoàn thành dự án
Xác định rõ các hạn chế, giả thuyết, điểm bên trong và bên ngoài
ích lợi của việc xác định phạm vi
HUT, Falt. of IT Dept. of SE, 2001 SE-II.22
Các tiêu thức của Xác định tốt
Rõ ràng không có ngôn từ nhập nhằng không có ngôn ngữ marketing và bán hàng không có từ viết tắt
Ngắn gọn 25 từ hoặc ít hơn nêu “là gì” chứ không phải “như thế nào”
Đầy đủ Trình bày phạm vi, lịch trình, nguồn Sử dụng các động từ hành động
HUT, Falt. of IT Dept. of SE, 2001 SE-II.23
PM
đội chủ chốt
đội mở rộng
văn phòng dự án
Nhà tài trợ dự án
ban điều hành dự án
đội quản lý
Tổ chức dự án
HUT, Falt. of IT Dept. of SE, 2001 SE-II.24
Kết quả bàn giao đáp ứng tiêu chuẩn
Tối thiểu hoá các rủi ro dự án
Kế hoạch làm việc được xây dựng phù hợp với mẫu
Tiến trình được đo lường, ghi chép và báo cáo
Các trở ngại được xác định và chỉ ra
Đảm bảo quy trình kiểm soát dự án...
HUT, Falt. of IT Dept. of SE, 2001 SE-II.25
Theo dõi & xem xét các dữ liệu mục tiêu
Rà xét các kết quả bàn giao
Báo cáo và phân tích tiến trình
Tái định hướng dự án khi cần thiết
Lựa chọn phần mềm quản lý dự án
Quy trình báo cáo và kiểm soát dự án
HUT, Falt. of IT Dept. of SE, 2001 SE-II.26
Các chính sách
Các thủ tục hành chính
Các tiêu chuẩn
Sổ tay quản trị
HUT, Falt. of IT Dept. of SE, 2001 SE-II.27
Ban chỉ đạo và nhà tài trợ phải phê chuẩn:
Phạm vi của dự án
Phương pháp luận được sử dụng
Thành phần của đội dự án
Ước tính kỹ lưỡng về thời gian và chi phí
Quy trình đối với việc quản lý dự án
HUT, Falt. of IT Dept. of SE, 2001 SE-II.28
Các yếu tố thành công
Một kế hoạch quản lý hiệu quả Mô tả các tiêu thức thành công của một dự án; Phác thảo khung thời gian, ngân sách, và các kết quả bàn
giao chủ yếu ở mức chất lượng thiết kế; Xác định phưong pháp tiếp cận và khung thời gian tổng
quan đối với việc thực thi dự án; Xác định nguồn nhân lực cần thiết để thực hiện công việc dự
án; và, Xác định cơ sở hạ tầng cần thiết của dự án để kiểm soát dự
án có hiệu quả.
HUT, Falt. of IT Dept. of SE, 2001 SE-II.29
Điểm chủ yếu để hiểu một dự án là ♦ lập ra một cấu trúc hay một khuôn khổ cho tất cả cácvăn bản quản lý dự án
Nền tảng vững chắc cho quản lý dự án ♦Truyền thông
Kế hoạch quản lý là nền tảng cho việc quản lý một dự án
Các điểm chủ chốt đã học
HUT, Falt. of IT Dept. of SE, 2001 SE-II.30
III. Tổ chức dự án
Quản lý dự án CNTT
HUT, Falt. of IT Dept. of SE, 2001 SE-II.31
Các mục tiêu tổ chức dự án
Vào cuối phần này, người tham dự khoá học có thể:
Hiểu được tầm quan trọng của một tổ chức tốt
Thiết lập được cơ cấu đội dự án hiệu quả
Phân định vai trò và trách nhiệm
Thiết lập một quy trình quản trị dự án hữu hiệu
HUT, Falt. of IT Dept. of SE, 2001 SE-II.32
Các kết quả chuyển giao từ tổ chức dự án
Xác định “những người có ảnh hưởng” của dự án Xác định những lĩnh vực chủ yếu có lực cản Tác động qua lại yêu cầu đối với dự án trước khi thành lập bất cứ
uỷ ban hay hội đồng nào Danh sách các thành viên tiềm năng trong ban điều hành dự án
Biểu đồ tổ chức dự án: - cấu trúc quản lý dự án - cấu trúc đội dự án
Vai trò và trách nhiệm dự án
Mô tả công việc dự án Các quyền hạn của Hội đồng
Tên các thành viên trong đội dự án
HUT, Falt. of IT Dept. of SE, 2001 SE-II.33
Quy trình tổ chức dự án
Xác định vị trí
dự án trong tổ chức
Thiết kế tổ chức dự án
Lập thành văn bản vai trò và
trách nhiệm của dự án
Xây dựng mô tả công việc và quyền lợi của các vị trí
Lựa chọn đội dự án
Step 1
Step 2
Step 3
Step 4 Step 5
HUT, Falt. of IT Dept. of SE, 2001 SE-II.34
Ví dụ về cấu trúc Quản lý dự án
Ban điều hành dự án Chủ tịch = nhà tài trợ dự án
Quản lý đơn vị nghiệp vụ Quản lý bảo đảm chất lượng
Quản lý dự án
nhóm trưởng nhóm trưởng quản lý nhóm nhóm trưởng
nhóm trưởng nhóm trưởng nhóm trưởng
Quản lý văn phòng dự án
HUT, Falt. of IT Dept. of SE, 2001 SE-II.35
Những điểm chính:
Cơ cấu tổ chức dự án
Cơ cấu và con người là vô cùng quan trọng đối với sự thành công của dự án ♦ giám đốc dự án điều hành nhóm quản lý ♦ các mối quan hệ cần phải được thiết lập
Vai trò kiểm soát dự án phải luôn có trong nhiệm vụ kiểm soát và quản trị ♦ không cần thiết phải có cán bộ làm việc full time ♦ không thể được thực hiện bởi quản trị viên/giám đốc dự án
HUT, Falt. of IT Dept. of SE, 2001 SE-II.36
Vai trò và trách nhiệm của dự án
nhà tài trợ dự án “Người đứng đầu”, chủ sở hữu và nhà tài chính của dự án
giám đốc dự án đại diện cho nhà tài trợ dự án
ban chỉ đạo giám sát hoạt động dự án, hỗ trợ trong việc lập phương hướng để đưa ra quyết định
nhóm nghiệp vụ thừa nhận các kết quả bàn giao chủ yếu về nghiệp vụ
quản lý dự án điều phối dự án tổng thể, quản lý và giám sát (có sự hỗ trợ hành chính từ văn phòng dự án)
nhóm trưởng hàng ngày quản lý và kiêm soát tiến triển theo kế hoạch làm việc chi tiết
các thành viên nhóm hoàn thành nhiệm vụ
vai trò Trách nhiệm
HUT, Falt. of IT Dept. of SE, 2001 SE-II.37
Các yêu cầu về mô tả
Ngắn gọn và súc tích
Xác định rõ:
♦Các mục đích và mục tiêu cơ bản
♦Những trách nhiệm cơ bản
♦ Số thành viên
♦Họp thường kỳ
HUT, Falt. of IT Dept. of SE, 2001 SE-II.38
Văn phòng dự án là gì? Là trung tâm của:
Họp
Điều phối, kết hợp
Theo dõi
Giám sát, điều hành
Duy trì và thông báo các thông tin của dự án
HUT, Falt. of IT Dept. of SE, 2001 SE-II.39
Nhiệm vụ và trách nhiệm của văn phòng dự án
ph©n tÝch xu híng
s¬ ®å tæ chøc
kiÓm so¸t thay ®æi lËp b¸o c¸o
vÒ thùc tr¹ng
lËp b¶ng biÓu
®a ra c¸c gi¶i ph¸p sö dông
c¸c nguån duy tr×
kÕ ho¹ch
ng©n sach dù ¸n
lËp th viÖn vÒ c¸c v¨n b¶n tµi liÖu
lËp b¸o c¸o theo thêi gian
®a ra c¸c kÕt qu¶ kh«ng cÇn thÈm ®Þnh
gi¸m s¸t thêi gian
híng dÉn lËp kÕ ho¹ch
theo dâi lÞch tr×nh
dÞch thuËt
HUT, Falt. of IT Dept. of SE, 2001 SE-II.40
Tổ chức dự án - Các điểm chính đã học
Nhà tài trợ có trách nhiệm cao đối với tổ chức Hỗ trợ tích cực từ ban điều hành Phân định rõ trách nhiệm, thẩm quyền, trách nhiệm
giải trình Trao đổi hợp lý giữa cán bộ kỹ thuật và cán bộ chức
năng Hoàn thành công việc dự án với nguồn lực ít nhất Dòng thông tin liên lạc hiệu quả Tỉ lệ cán bộ so với người quản lý nhỏ Tối giản các mức báo cáo, loại trừ các yêu cầu không
cần thiết
Các nhân tố thành công đối với một cơ cấu tổ chức dự án mạnh:
HUT, Falt. of IT Dept. of SE, 2001 SE-II.41
IV. Quản lý rủi ro
Quản lý dự án CNTT
HUT, Falt. of IT Dept. of SE, 2001 SE-II.42
Những mục tiêu của phần này
Hiểu được sự cần thiết của quản lý rủi ro trong suốt quá trình thực hiện dự án
Có thể thực hiện việc phân tích và đánh giá rủi ro của dự án
Có thể thiết lập quy trình quản lý rủi ro hiệu quả
HUT, Falt. of IT Dept. of SE, 2001 SE-II.43
Định nghĩa rủi ro
Những sự kiện có thể làm phá vỡ một dự án
Những điều không chắc chắn, những khoản nợ hay những điểm yếu có thể làm cho dự án không đi theo đúng kế hoạch đã định
Có thể quản lý được
Rủi ro là:
HUT, Falt. of IT Dept. of SE, 2001 SE-II.44
Các lý do cần có quản lý rủi ro
Tất cả các dự án đều phụ thuộc vào rủi ro
Tiến trình sẽ không đúng theo kế hoạch trong một số giai đoạn của dự án
Rủi ro không thể được loại trừ triệt để
HUT, Falt. of IT Dept. of SE, 2001 SE-II.45
Định nghĩa quản lý rủi ro
Quy trình quản lý rủi ro nhằm giảm tối thiểu
ảnh hưởng của những sự cố không biết trước
cho dự án bằng cách xác định và đưa ra những
giải pháp tình huống trước khi có những hậu
quả xấu xảy ra
HUT, Falt. of IT Dept. of SE, 2001 SE-II.46
Giảm thiểu ảnh hưởng của các sự cố không biết trước cho dự án
Nâng cao xác suất thực hiện thành công dự án
Tạo ra ý thức kiểm soát Có được các giải pháp hiệu quả và kịp thời
Giá trị của quản lý rủi ro
HUT, Falt. of IT Dept. of SE, 2001 SE-II.47
Khi nào cần quản lý rủi ro
Lập kế hoạch quản lý Khi trách nhiệm đối với dự án sẵn sàng
thực thi Khi khôi phục một dự án đã bỏ dở Trong suốt quá trình rà xét dự án khi có sự sai lệch lớn so với kế hoạch xảy
ra
HUT, Falt. of IT Dept. of SE, 2001 SE-II.48
Quy trình quản lý rủi ro
Xác định mức rủi ro ban đầu của dự án lập thành
văn bản các rủi ro cụ
thể tiến hành phân tích ảnh hưởng rủi ro
xây dựng và triển khai kế hoạch quản lý
rủi ro
giám sát và cập nhật các tài liệu rủi ro
Xác định Phân tích Quản lý Giám sát
bước 1
bước 2
bước 3
bước 4
HUT, Falt. of IT Dept. of SE, 2001 SE-II.49
Hoạt động ngăn ngừa (ví dụ)
Đưa ra đào tạo bổ sung cho các lập trình viên (để giảm rủi ro tiềm năng) hoặc
Thuê hợp đồng với các lập trình viên có nhiều kinh nghiệm (loại bỏ rủi ro tiềm năng)
Đội dự án có thể bị chậm so với lịch trình trong giai đoạn xây dựng phần mềm vì các nhà lập trình đang ở trong giai đoạn rất khó mã các chương trình hơn dự đoán. Xác suất khoảng 30 % là nhân viên hiện tại không thể đáp ứng các sự kiện sắp tới đúng hạn. Hành động ngăn ngừa có thể gồm:
HUT, Falt. of IT Dept. of SE, 2001 SE-II.50
Hành động dự phòng
Phải: Dựa trên những thừa nhận từ thực
tiễn (ví dụ: các nguồn sẵn có) Các thành viên trong nhóm phải hiểu
được (và uỷ ban điều hành) Phải được kiểm tra khi tính khả thi
bị nghi ngờ
HUT, Falt. of IT Dept. of SE, 2001 SE-II.51
Các điểm chính đã học Chương trình quản lý rủi ro hiệu quả
Tập trung vào việc phòng ngừa hơn là chữa trị
Bao gồm đánh giá rủi ro theo thời kỳ trong suốt vòng đời của dự án
Kết hợp chặt chẽ một quy trình liên tục về xác định rủi ro, phân tích, quản lý và rà xét
Nhận biết giá trị của quyền hạn....... không đi quá giới hạn và kết thúc không chính xác! Sự hợp lý của quản lý rủi ro chuẩn sẽ không tốn
những nỗ lực vô lý.
HUT, Falt. of IT Dept. of SE, 2001 SE-II.52
V. Phát triển nhóm
Quản lý dự án CNTT
HUT, Falt. of IT Dept. of SE, 2001 SE-II.53
Xây dựng nhóm - Các mục tiêu
Xây dựng hiểu biết của bạn về các đặc tính của nhóm làm việc hiệu quả
Xác định các phương pháp để xây dựng nhóm có hiệu quả
HUT, Falt. of IT Dept. of SE, 2001 SE-II.54
Nhóm hiệu quả Các mục đích được thống nhất Nhóm tin tưởng vào vai trò và mục tiêu Chấp thuận về các mục tiêu dự án và chất
lượng dự án. Truyền thông đối lưu hiệu quả Các ý tưởng được trao đổi và triển khai Đưa ra các giải pháp hiệu quả Mối quan hệ hợp tác và hỗ trợ giữa các thành
viên của nhóm
HUT, Falt. of IT Dept. of SE, 2001 SE-II.55
thành lập xung kích Quy chuẩn thực hiện
xây dựng nhóm
lịch trình của từng thành viên
hợp tác cam kết
Quy trình xây dựng nhóm
thực hiện nhóm
HUT, Falt. of IT Dept. of SE, 2001 SE-II.56
Xây dựng nhóm - các điểm chính đã học
Mục tiêu rõ ràng
Trách nhiệm rõ ràng
Thông tin liên lạc hiệu quả
Phản hồi có tính xây dựng
Lãnh đạo linh hoạt
Cán bộ đủ khả năng
Xác định với nhóm
Nhóm làm việc thành công được xây dựng trên cơ sở:
HUT, Falt. of IT Dept. of SE, 2001 SE-II.57
VI. Quản lý chất lượng
Quản lý dự án CNTT
HUT, Falt. of IT Dept. of SE, 2001 SE-II.58
Hai Định nghĩa về Chất lượng
Thích hợp với mục đích
Giảm tối đa sự lãng phí bằng cách thực hiện đúng ngay từ lần đầu
HUT, Falt. of IT Dept. of SE, 2001 SE-II.59
Thoả mãn nhu cầu
mục đích
thực hiện phương pháp
Cân bằng chất lượng
HUT, Falt. of IT Dept. of SE, 2001 SE-II.60
Các khái niệm chất lượng chủ chốt
Đạt được về chất lượng phải đựoc lên kế hoạch - không tuỳ tiện
Đạt được về chất lượng xuất phát từ bảo đảm chất lượng và kiểm soát chất lượng
Đạt được chất lượng phụ thuộc vào sự hỗ trợ quản lý
HUT, Falt. of IT Dept. of SE, 2001 SE-II.61
Quản lý chất lượng
1.Lập kế haọch chất lượng
2.Thiết lập khung đảm bảo chất
lượng
3. Tiến hành các hoạt động kiểm soát chất lượng
4. Triển khai các họat động hiệu
chỉnh
HUT, Falt. of IT Dept. of SE, 2001 SE-II.62
Những điểm chủ chốt đã học
Cam kết quản lý Người sử dụng tham gia Cấu trúc của phương pháp tiếp cận Các yêu cầu chất lượng có thể đo lường được Thẩm định các phương pháp, kiểm soát, quy trình
và sản phẩm của dự án Thông tin liên lạc và một kế hoạch có chất lượng tốt sẽ mô tả việc làm
thế nào để tất cả những điều này được quản lý
Các nhân tố quản lý chất lượng hiệu quả:
HUT, Falt. of IT Dept. of SE, 2001 SE-II.63
VII. Lập kế hoạch làm việc chi tiết
Quản lý dự án CNTT
HUT, Falt. of IT Dept. of SE, 2001 SE-II.64
Các mục tiêu đối với phần này
Giải thích mối quan hệ giữa Kế hoạch hoạt động (một phần của kế hoạch quản lý) và Kế hoạch làm việc
Nhìn vào các yếu tố cuả một kế hoạch: Tài liệu về nhiệm vụ Các phụ thuộc Các nguồn lực
Để giải thích chu kỳ lập kế hoạch làm việc
Để nhấn mạnh tầm quan trọng của ranh giới công việc
Nêu bật đặc điểm của một kế hoạch làm việc tốt
HUT, Falt. of IT Dept. of SE, 2001 SE-II.65
Làm thế nào để tạo một kế hoạch làm việc
Tách các giai đoạn thành từng hoạt động
Tách các hoạt động thành từng nhiệm vụ
Các nhiệm vụ nhỏ dễ dàng ước tính và quản lý hơn từng giai đoạn lớn
Các nhiệm vụ cần:
♦ thường không nhỏ hơn 7 người/giờ làm việc
♦ thường không nhiều hơn 70 người/giờ làm việc
♦ thường không sử dụng nhiều hơn 2 nguồn
♦ thường xuyên có một văn bản nhiệm vụ xác định
HUT, Falt. of IT Dept. of SE, 2001 SE-II.66
Giai ®o¹n Møc 1
ho¹t ®éng ho¹t ®éng Møc 2
nhiÖm vô
nhiÖm vô
nhiÖm vô
nhiÖm vô
Møc 3...
Cấu trúc phân chia công việc (WBS)
HUT, Falt. of IT Dept. of SE, 2001 SE-II.67
Lập kế hoạch - Xây dựng WBS
Mục tiêu nghiệp vụ
kế hoạch hoạt động
định nghĩa kế hoạch
Các hoạt động cần đạt được các kết quả bàn giao mốc đã được xác định trong WBS
Kết quả bàn giao
Xác định kết quả bàn giao
HUT, Falt. of IT Dept. of SE, 2001 SE-II.68
Nhiệm vụ phải được xác định là:
Xác định nhiệm vụ
được thiết kế để đưa ra kết quả bàn giao (như là một phần của một hoạt động)
trách nhiệm của một cá nhân
có hạn
♦ xác định tiêu thức đối với việc bắt đầu và kết thúc
đơn vị công việc có thể quản lý được
dễ hiểu
có thể đo lường được
HUT, Falt. of IT Dept. of SE, 2001 SE-II.69
Xác định các nhiệm vụ phụ thuộc Không bị cản trở do các nguồn trong giai đoạn này
Hỏi “Công việc gì cần hoàn thành trước khi nhiệm vụ này có thể bắt đầu?”
Hỏi “Những nhiệm vụ gì có thể được thực hiện khi công việc này kết thúc?”
Giảm tối đa một chuỗi dài các nhiệm vụ phụ thuộc
Thực hiện các nhiệm vụ song song với nhau khi có thể
Xem xét những khoảng cách
Xem xét sự chồng chéo
Chuyển các thông tin phụ thuộc vào thành một công cụ lập kế hoạch
HUT, Falt. of IT Dept. of SE, 2001 SE-II.70
Chỉ định nguồn lực cho các nhiệm vụ
Các nguyên tắc cơ bản
Sử dụng hợp lý nguồn Kinh nghiệm & kỹ năng đáp ứng
nhu cầu nhiệm vụ không bỏ qua những cán bộ thiếu
kinh nghiệm Sự sẵn sàng không phải là một kỹ năng
HUT, Falt. of IT Dept. of SE, 2001 SE-II.71
Các nguồn của dự án được cam kết để đạt được mục tiêu của dự án. các nguồn được Quản trị viên dự án tổ chức và chỉ đạo để đạt được mục tiêu của dự án trong phạm vi chi phi và lịch trình cho phép.
Các loại nguồn tiêu biểu bao gồm:
Nguồn lực của dự án là những gì?
Con người - là những người được lựa chọn cho đội dự án. Họ thể hiện các kinh nghiệm và kỹ năng sẵn sàng để hoàn thành mục tiêu.
Thiết bị - Thiết bị cần thiết cho dự án. Nó có thế bao gồm từ những thiết bị lớn đến máy tính và những công cụ kiểm tra đặc biệt.
Văn phòng phẩm - là những đồ dùng cần thiết cho dự án. Nó có thể bao gồm những thứ từ giấy và bút chì đến đĩa mềm và các đồ vật khác.
Tài chính - các nguồn tài chính là tiền đôla và các cam kết cần thiết để thu được khi cần thiết, nguồn thu nhập của dự án.
HUT, Falt. of IT Dept. of SE, 2001 SE-II.72
Lên lịch trình nên... Giảm tối đa thời gian bỏ phí Tận dụng tối đa các nguồn Dàn xếp chỗ thừa và chỗ thiếu của các nguồn Xem xét các hạn chế của:
♦ các nhiệm vụ phụ thuộc ♦ các nguồn sẵn có
Là một quy trình lặp lại ♦ thời gian biểu của quy trình ♦ rà xét thời gian biểu ♦ sửa thời gian biểu ♦ lập lại thời gian biểu
Hoàn thành với một công cụ lên lịch trình tự động
HUT, Falt. of IT Dept. of SE, 2001 SE-II.73
10 đặc điểm của một kế hoạch làm việc tốt 1 Chia nhỏ một giai đoạn lớn và phức tạp (tức là kế hoạch quản lý)
thành nhiều nhiệm vụ có thể quản lý được 2 Xác định phạm vi và mục tiêu của từng nhiệm vụ 3 Xác định những nguồn nào cần để thực hiện từng nhiệm vụ 4 Xác định thời gian cần sử dụng nguồn của từng nhiệm vụ 5 Xác định thời điểm bắt đầu và kết thúc của từng nhiệm vụ 6 Bao gồm các ước tính thực tế 7 Giảm tối đa sự thất thường của công việc khi sử dụng từng nguồn 8 Kết hợp chi phí của các nhiệm vụ và dự phòng 9 Tiêu chuẩn hoá dự án để có thể giám sát được 10 Đưa ra việc bảo trì đơn giản và cập nhật các công việc thực tế
HUT, Falt. of IT Dept. of SE, 2001 SE-II.74
Các nhân tố thành công Những điều đã học được
Một kế hoạch làm việc tốt xác định được các mục tiêu và phạm vi của lượng công việc có thể quản lý được
Nó xác định sự nỗ lực, nguồn và lịch trình sẽ đáp ứng nhu cầu của từng mục tiêu
Nó rất thực tế và bao gồm phần dự phòng
Nó sử dụng các nguồn hiệu quả và hợp lý
Nó thiết lập một tiêu chuẩn để kiểm tra tiến trình công việc
Nó rất dễ duy trì vì luôn sẵn có nhiều thông tin
HUT, Falt. of IT Dept. of SE, 2001 SE-II.75
VIII. Kiểm soát và lập báo cáo dự án
Quản lý dự án CNTT
HUT, Falt. of IT Dept. of SE, 2001 SE-II.76
Lập báo cáo và kiểm soát dự án - các mục tiêu Để có thể : Chứng minh sự cần thiết trong việc lập báo cáo và kiểm
soát dự án hiệu quả và giải thích các lợi ích Để nhận biết các phương pháp và kỹ năng khác nhau có thể
được sử dụng cho việc lập báo và kiểm soát dự án Đánh giá tầm quan trọng của việc trình bày các thông tin
hhiện trạng hợp lý cho các thính giả khác nhau Đánh giá tầm quan trọng cuả một chu kỳ kiểm soát dự án
được xác định.
HUT, Falt. of IT Dept. of SE, 2001 SE-II.77
Các định nghĩa
Kiểm soát dự án:
Nắm bắt và quản lý tiến trình
Lập báo cáo dự án:
Truyền bá hiệu quả những kiến thức này
HUT, Falt. of IT Dept. of SE, 2001 SE-II.78
Quản trị viên dự án có thể: ♦ Báo cáo khách quan về thực trạng dự án
♦ Xác định những cản trở và hành động hiệu chỉnh
♦ Triển khai các giải pháp
♦ Hiểu sự ảnh hưởng của công việc tương lai
♦ Đưa ra những quyết định hợp lý dựa trên thông tin xác thực
Quản trị viên dự án, trưởng nhóm và thành viên nhóm phải: ♦ Lắng nghe tin nhắn chuyển đến
♦ Chấp nhận tin xấu và tốt ♦ Hỗ trợ tích cực các thành viên trong nhóm để vượt qua trở ngại
Lập báo cáo và kiểm soát dự án là nền tảng để quản lý dự án
HUT, Falt. of IT Dept. of SE, 2001 SE-II.79
Lập báo cáo hiệu quả về thực trạng và các vấn đề của toàn bộ dự án sẽ:
Trao đổi tình trạng dự án
Tập trung vào các thành tựu của các mục tiêu kinh doanh, chứ không phải vào quy trình dự án
Đưa ra thông tin chính xác tin cậy dựa trên kế hoạch dự án
Nêu bật những điểm ngoại lệ so với kế hoạch
Cung cấp thông tin kịp thời Bao gồm cả mức nỗ lực có thể chấp nhận
HUT, Falt. of IT Dept. of SE, 2001 SE-II.80
Dự án
Giai đoạn
Phạm vi
Nhiệm vụ
Hoạt động
Bước t/h
Mức WBS
1
2
3
4
5 Chi tiết đội dự án
Quan sát bên ngoài
Lập báo cáo - the WBS
HUT, Falt. of IT Dept. of SE, 2001 SE-II.81
Lập kế hoạch, theo dõi, báo cáo
C¸c môc tiªu kinh doanh
KÕt qu¶ bµn giao
X¸c ®Þnh kÕt qu¶ bµn giao
kÕ ho¹ch ho¹t ®éng
x¸c ®Þnh kÕ ho¹ch
D÷ liÖu hiÖn t¹i - ®Çy ®ñ - cè g¾ng - chi phÝ KÕ ho¹ch cËp nhËt
B¸o c¸o thùc tr¹ng
C¸c b¸o c¸o tõ kÕ haäch
B¸o c¸o c¸c vÊn ®Ò
X¸c ®Þnh vÊn ®Ò
tham gia cña v¨n phßng dù ¸n
HUT, Falt. of IT Dept. of SE, 2001 SE-II.82
Lập báo cáo và kiểm soát dự án
Replan/ Rebaseline
quản lý thực hành
kế hoạch quản lý
KH công việc chi tiết
dữ liệu tiến trình
dữ liệu hoàn thiện
khác
dữ liệu nhiệm vụ
quản lý nguồn
kiểm soát khác
giải pháp
lập báo cáo
hiện trạng
xu hướng
nguồn
tài chính
thay đổi
phiên bản
vấn đề
chất lương
phân tích hoạt động hiệu chnh
kế hoạch công việc chi tiết
theo dõi và rà xét các dữ kiện mục tiêu
rà xét các KQBG và nỗ lực
báo cáo và phân tích tiến trình
Tái định hướng dự án
Các bước
HUT, Falt. of IT Dept. of SE, 2001 SE-II.83
Khuôn khổ kiểm soát dự án C«ng viÖc kiÓm so¸t Møc
kiÓm so¸t B¸o c¸o
Ban ®iÒu hµnh
Qu¶n trÞ viªn dù ¸n
Trëng nhãm
Nhãm
B/c Ban ®iÒu hµnh
B/c Qu¶n trÞ viªn dù ¸n
B/c trëng nhãm
B/c thµnh viªn nhãm
kÕ ho¹ch qu¶n lý
kÕ ho¹ch c«ng viÖc chi tiÕt kÕ ho¹ch c«ng viÖc chi tiÕt danh môc nhiÖm vô
kÕ ho¹ch qu¶n lý
HUT, Falt. of IT Dept. of SE, 2001 SE-II.84
Một chu kỳ kiểm soát dự án thống nhất:
Chu kỳ kiểm soát dự án
Nêu rõ ràng chu kỳ các sự kiện cho việc lập báo cáo thực trạng
Xác định các thông tin thông thường được yêu cầu với các mức điều hành, quản lý, nhóm
Thiết lập thời gian biểu cho việc lập báo cáo yêu cầu đối với từng mức
HUT, Falt. of IT Dept. of SE, 2001 SE-II.85
Chu kỳ kiểm soát dự án - các yếu tố
HĐQT
Uỷ ban điều hành
Các giám đốc dự án Các nhà tài trợ kinh doanh
Chủ thực hiện
Ai Khi nào
Chủ thực hiện Quản trị viên dự án Quản lý kinh doanh
hàng tháng: thứ sáu
2 tuần 1 lần: thứ hai
2 tuần 1 lần: thứ tư
hàng tuần: thứ sáu
Các báo cáo và biên bản hiện trạng tiêu chuẩn hoá do v/phòng d/a điều phối
Các giám đốc dự án
Nhóm và Quản trị viên dự án
quản lý đơn vị kinh doanh
HUT, Falt. of IT Dept. of SE, 2001 SE-II.86
Các nhân tố thành công
Không sử dụng thông tin riêng biệt
Sử dụng các báo cáo thích hợp cho từng đối tượng
Nắm bắt những lợi thế của thông tin
♦ không thoả mãn
♦ không hoảng sợ
HUT, Falt. of IT Dept. of SE, 2001 SE-II.87
Những điểm chính: Lập báo cáo & kiểm soát dự án
Thiết lập, dự đoán chu kỳ đối với việc lập báo cáo hiện trạng
Kế hoạch thực tế, đúng lúc dựa trên thông tin được báo cáo ở mức nhóm, quản lý, điều hành
Các phương pháp trình bày đa dạng thích hợp với từng đối tượng và công việc được giao
Yêu cầu môi trường hỗ trợ về truyền thông
HUT, Falt. of IT Dept. of SE, 2001 SE-II.88
IX. Quản lý vấn đề và kiểm soát thay đổi
Quản lý dự án CNTT
HUT, Falt. of IT Dept. of SE, 2001 SE-II.89
Quản lý sự thay đổi và vấn đề
Giúp các thành viên có thể: Xác định các nguyên nhân có thể
làm nên sự thay đổi trong một dự án
Hiểu tầm quan trọng và lợi ích của việc thiết lập kiểm soát sự thay đổi và các quy trình giải quyết sự kiện
Các mục tiêu
HUT, Falt. of IT Dept. of SE, 2001 SE-II.90
Các thành viên tham gia dự án cần được khuyến khích đối với các tài liệu về sự kiện hay các thay đổi đề xuất khi họ nêu ra
♦phản hồi, hành động, tuyên truyền nhanh chóng để giảm rủi ro
Các thành viên của nhóm cần hiểu quy trình quản lý sự thay đổi và vấn đề
Ghi chép toàn diện được yêu cầu đối với việc kiểm soát và truyền thông
♦ bao gồm tất cả các khoản mục hiện tại và đã hoàn thiện
Các phương tiện quản lý sự kiện và thay đổi hiệu quả:
Về nguyên tắc
HUT, Falt. of IT Dept. of SE, 2001 SE-II.91
Quản lý thay đổi và vấn đề - Tại sao?
Hai trong số những lý do thông thường nhất đối với sự thất bại của dự án:
Không nhận ra sự thay đổi và vấn đề, và
Không quản lý hiệu quả những vấn đề này
HUT, Falt. of IT Dept. of SE, 2001 SE-II.92
Kiểm tra • Đơn vị • Khối • Tích hợp • Chấp thuận
Programmer fine tuning • needed • nice to have
các nguồn cụ thể của dự án rà xét
kiểm soát chất lượng
chuyển đổi
Các quyết định về chính sách và
nghiệp vụ
các tổ chức bên ngoài
Xuất hiện nhà cung cấp phần mềm mới
Các đánh giá khác nhau của người sử dụng
Các yêu cầu mới và đưa ra những
khám phá Luật pháp
các nguồn thay đổi tiềm
năng
HUT, Falt. of IT Dept. of SE, 2001 SE-II.93
Định nghĩa thay đổi: bất cứ hoạt động nào thay đổi: phạm vi kết quả bàn giao kiến trúc cơ bản chi phí lịch trình của một dự án
Giải pháp quản lý vấn đề và thay đổi
HUT, Falt. of IT Dept. of SE, 2001 SE-II.94
Kiểm soát thay đổi và giải pháp cho vấn đề
Giảm rủi ro dự án nhờ quy trình hiệu quả quản lý thay đổi và vấn đề
Các thành viên nhóm hiểu được quy trình quản lý thay đổi và vấn đề
Ghi chép đầy đủ về các yêu cầu thay đổi/ vấn đề
Các nhân tố thành công
HUT, Falt. of IT Dept. of SE, 2001 SE-II.95
Chi phí thay đổi
Chi phí thay đổi
Req. Design Code Test Live
HUT, Falt. of IT Dept. of SE, 2001 SE-II.96
Các điểm chính đã học Quản lý thay đổi và vấn đề
Việc quản lý vấn đề và thay đổi là yếu tố chủ yếu trong phạm vi kiểm soát dự án
Hệ thống quản lý thay đổi và vấn đề có thể đóng vai trò chủ đạo trong việc truyền thông dự án
Một hệ thống chính thống, hiệu quả không yêu cầu quá nhiều chi phí quản lý hành chính
HUT, Falt. of IT Dept. of SE, 2001 SE-II.97
X. Quản lý cấu hình
Quản lý dự án CNTT
HUT, Falt. of IT Dept. of SE, 2001 SE-II.98
Các mục tiêu của phần này
Sau khi kết thúc phần này, bạn sẽ hiểu:
CM là gì và tại sao sự thành công của dự án phụ thuộc vào nó
Những việc thiết lập và các nhiệm vụ kế tiếp nào cần được thực hiện để triển khai CM được hiệu quả
Các công cụ CM có thể giúp như thế nào
HUT, Falt. of IT Dept. of SE, 2001 SE-II.99
Quản lý Cấu hình
Đa số nghĩ rằng...
Đây là vấn đề về LANs, WANs, phần cứng, ...
Đây là các hoạt động mang tính kỹ thuật cao
Nó liên quan rất ít đến quản lý dự án
HUT, Falt. of IT Dept. of SE, 2001 SE-II.100
Quản lý cấu hình
...thực hiện hai chức năng chính
Cung cấp việc truy cập an toàn và đơn giản đối với bản copy tổng thể về các kết quả bàn giao đã được thông qua
Kiểm soát được thực trạng của các kết quả bàn giao và mối quan hệ qua lại lẫn nhau giữa các kết quả này
HUT, Falt. of IT Dept. of SE, 2001 SE-II.101
Quản lý cấu hình
Cung cấp một kho chứa an toàn đối với các kết quả bàn giao
Cho phép việc kiểm soát và tiết lộ có nguyên tắc các kết quả bàn giao thông qua vòng đời của nó, với đầy đủ các dấu tích lịch sử, đảm bảo phiên bản đúng và cập nhật, đã được kiểm tra và phát hành
Kiểm soát thay đổi cuả các kết quả bàn giao, đảm bảo các kết quả này được lưu theo đúng thứ tự
Cung cấp việc lập báo cáo về hiện trạng của các kết quả bàn giao và những thay đổi của chúng
Các kỹ thuật và quy trình ...
HUT, Falt. of IT Dept. of SE, 2001 SE-II.102
0.1 0.2 0.n
1.1 1.2 1.n
1.0
2.0
Approved
Kiểm soát phiên bản
HUT, Falt. of IT Dept. of SE, 2001 SE-II.103
Bổ sung khoản mục mới (1)
Kho QL Cấu hình
Gửi mục & baseline (4)
Trả lại mục được Cập nhật (3)
Backup / lưu giữ (5)
Các báo cáo Kiểm soát (6)
Lấy mục để cập nhật (2)
Các chức năng quản lý cấu hình
HUT, Falt. of IT Dept. of SE, 2001 SE-II.104
Các điểm chính đã học
Tính thống nhất của tất cả các kết quả bàn giao dự án được bảo vệ
Truy cập vào các khoản mục cấu hình được kiểm soát hiệu quả, nhưng không phức tạp đối với các thành viên nhóm được uỷ quyền
Một danh sách tổng thể về các khoản mục cấu hình, với các thông tin hiện tại, luôn sẵn có, và
Các thành viên nhóm hiểu và thích ứng với quy trình quản lý cấu hình
Một quy trình quản lý cấu hình hiệu quả phải có các đặc tính sau:
HUT, Falt. of IT Dept. of SE, 2001 SE-II.105
XI. Hoàn tất dự án
Quản lý dự án CNTT
HUT, Falt. of IT Dept. of SE, 2001 SE-II.106
Sau khi kết thúc phần này, bạn sẽ: Hoàn thiện dự án
Hiểu được nhân tố căn bản và phương pháp QLDA đối với giai đoạn hoàn thiện dự án
Hiểu được tầm quan trọng của Việc rà xét Sau thực hiện
HUT, Falt. of IT Dept. of SE, 2001 SE-II.107
Hoàn tất dự án là việc giải thể tổ chức và môi trường dự án theo phương thức đã được ấn định sau khi đã đạt được các mục tiêu của dự án và tất cả các nhiệm vụ trong kế hoạch làm việc chi tiết được hoàn thành.
Hoàn thiện dự án
HUT, Falt. of IT Dept. of SE, 2001 SE-II.108
Nguyên tắc
Quy trình đối với việc hoàn tất dự án cần được lập kế hoạch với sự chú ý vào từng chi tiết giống như các giai đoạn khác của dự án
Vai trò và trách nhiệm con người trải qua sự thay đổi lớn vào thời điểm cuối cùng của dự án
Các kế hoạch đối với việc hoàn tất dự án cần lên lịch các hoạt động yêu cầu của Rà xét sau thực hiện
HUT, Falt. of IT Dept. of SE, 2001 SE-II.109
Quy trình hoàn thiện dự án Rà xét và cập nhật kế hoạch quản lý Xây dựng kế hoạch làm việc chi tiết cho việc hoàn tất dự án Tiến hành rà xét các hoạt động Kết thúc hợp đồng với các nhà thầu phụ Chuẩn bị các báo cáo dự án cuối cùng Lập thành văn bản và lưu giữ các kết quả bàn giao dự án Đóng văn phòng dự án Giải thể tổ chức dự án Tiến hành các cuộc họp kết thúc dự án Tiến hành rà xét sau thực hiện Thiết lập lại việc phân bổ nhân sự
HUT, Falt. of IT Dept. of SE, 2001 SE-II.110
Tiến hành các cuộc họp kết thúc dự án
Xem xét các yêu cầu dự án các mục tiêu dự án phạm vi dự án các kết quả bàn giao chính phương pháp tiếp cận dự án lịch trình ở mức cao
Xem xét các thành quả dự án nền tảng kết quả bàn giao đặc tính nổi bật các lợi ích lớn đã đạt được
Thực trạng cuối cùng kế hoạch so với thực tế phân tích sự khác nhau và thảo
luận Xem xét các khoản mục mở danh mục nổi bật danh mục các vấn đề thay đổi Khái quát các bước tiếp theo hoàn tất lịch trình chuyển đổi các mục tiêu/ kế hoạch đối với rà
xét sau thực hiện
Lịch trình
HUT, Falt. of IT Dept. of SE, 2001 SE-II.111
Tiến hành rà xét sau thực hiện Quy trình và việc hoàn tất dự án
♦ tiến hành tại thời điểm kết thúc dự án • thực hiện và theo dõi trong khuôn khổ dự án
Lợi ích kinh doanh/ tính hiệu quả của dự án
♦Tiến hành vài tháng sau khi triển khai • Thực hiện và theo dõi ngoài dự án • các nhu cầu cần được thiết lập trong lịch trình hoạt động và thứ tự ưu tiên (sau dự án) của các thành viên
HUT, Falt. of IT Dept. of SE, 2001 SE-II.112
Rà xét sau triển khai
Thành công phụ thuộc vào việc có các mục tiêu dự án rõ ràng với các biện pháp thực hiện ♦rất khó để xác định khi nào bạn đạt được một mục tiêu không được nói rõ!
Cải tiến quy trình dự án có thể được xác
định ♦nó cũng phải được triển khai!
HUT, Falt. of IT Dept. of SE, 2001 SE-II.113
Các nhân tố thành công
Kế hoạch làm việc toàn diện được xây dựng Việc đánh giá quá trình triển khai được tiến
hành Các báo cáo dự án cuối cùng được phát hành,
các kết quả bàn giao được lưu giữ Giải thể chính thức tổ chức của dự án Việc rà xét toàn diện sau triển khai được tiến
hành
HUT, Falt. of IT Dept. of SE, 2001 SE-II.114
Các điểm chính đã học Hoàn chỉnh dự án
Việc giải thể theo thứ tự cơ cấu dự án yêu cầu sự cẩn thận không kém việc xây dựng nên dự án
Rà xét sau thực hiện là một cơ hội tốt đối với nghiên cứu của cá nhân cũng như tổ chức
Nhưng... Nó phải được lập kế hoạch và tiến hành để đảm bảo việc tập trung tích cực vào các mục tiêu kinh doanh của dự án và tổ chức
HUT, Falt. of IT Dept. of SE, 2002 SE-III.1
Nhập môn Công nghệ học Phần mềm
Introduction to Software Engineering
Department of Software Engineering Faculty of Information Technology
Hanoi University of Technology TEL: 04-8682595 FAX: 04-8692906
Email: [email protected]
HUT, Falt. of IT Dept. of SE, 2002 SE-III.2
Phần III Yêu cầu người dùng User’s Requirements
Chương 5: Phương pháp xác định yêu cầu 5.1. Kỹ thuật xác định yêu cầu 5.2. Nội dung xác định yêu cầu 5.3. Các nguyên lý phân tích yêu cầu
HUT, Falt. of IT Dept. of SE, 2002 SE-III.3
5.1. Kỹ thuật xác định yêu cầu phần mềm SW Requirements Engineering
• Yêu cầu phần mềm: là tất cả các yêu cầu về phầm mềm do khách hàng - người sử dụng phần mềm - nêu ra, bao gồm: các chức năng của phần mềm, hiệu năng của phần mềm, các yêu cầu về thiết kế và giao diện, các yêu cầu đặc biệt khác
HUT, Falt. of IT Dept. of SE, 2002 SE-III.4
• Thông thường các yêu cầu phần mềm được phân loại theo 4 thành phần của phần mềm: – Các yêu cầu về phần mềm (Software) – Các yêu cầu về phần cứng (Hardware) – Các yêu cầu về dữ liệu (Data) – Các yêu cầu về con người (People, Users)
• Mục đích: mục đích của yêu cầu phần mềm là xác định được phần mềm đáp ứng được các yêu cầu và mong muốn của khách hàng - người sử dụng phần mềm
HUT, Falt. of IT Dept. of SE, 2002 SE-III.5
Tại sao cần phải đặt ra yêu cầu phần mềm ?
• Khách hàng chỉ có những ý tưởng còn mơ hồ về phần mềm cần phải xây dựng để phục vụ công việc của họ, chúng ta phải sẵn sàng, kiên trì theo đuổi để đi từ các ý tưởng mơ hồ đó đến “Phần mềm có đầy đủ các tính năng cần thiết”
• Khách hàng rất hay thay đổi các đòi hỏi của mình, chúng ta nắm bắt được các thay đổi đó và sửa đổi các mô tả một cách hợp lý
HUT, Falt. of IT Dept. of SE, 2002 SE-III.6
5.2. Nội dung xác định yêu cầu phần mềm
Contents of Requirements Engineering • Phát hiện các yêu cầu phần mềm (Requirements
elicitation) • Phân tích các yêu cầu phần mềm và thương lượng với
khách hàng (Requirements analysis and negotiation) • Mô tả các yêu cầu phần mềm (Requirements
specification) • Mô hình hóa hệ thống (System modeling) • Kiểm tra tính hợp lý các yêu cầu phần mềm
(Requirements validation) • Quản trị các yêu cầu phần mềm (Requirements
management)
HUT, Falt. of IT Dept. of SE, 2002 SE-III.7
Quy trình xác định yêu cầu phần mềm
the problem Requirements
elicitation
Build a prototype
Create analysis models
Develop specification Review
HUT, Falt. of IT Dept. of SE, 2002 SE-III.8
The Analysis Model
Data Model
Behavioral Model
Functional Model
HUT, Falt. of IT Dept. of SE, 2002 SE-III.9
5.2.1. Phát hiện yêu cầu phần mềm
(Requirements Elicitation) Các vấn đề của phát hiện yêu cầu phần mềm (Problems)
• Phạm vi của phần mềm (Scope) • Hiểu rõ phần mềm (Understanding) • Các thay đổi của hệ thống (Volatility)
HUT, Falt. of IT Dept. of SE, 2002 SE-III.10
Phương pháp phát hiện yêu cầu phần mềm Requirements Elicitation Methodology
• Xác định các phương pháp sử dụng phát hiện các yêu cầu phần mềm: phỏng vấn, làm việc nhóm, các buổi họp, gặp gỡ đối tác, v.v.
• Tìm kiếm các nhân sự (chuyên gia, người sử dụng) có những hiểu biết sâu sắc nhất, chi tiết nhất về hệ thống giúp chúng ta xác định yêu cầu phần mềm
• Xác định “môi trường kỹ thuật - technical environment” • Xác định các “ràng buộc lĩnh vực domain constraints” • Thu hút sự tham gia của nhiều chuyên gia, khách hàng để chúng ta có được các quan điểm xem xét phần mềm khác nhau từ phía khách hàng
• Thiết kế các kịch bản sử dụng của phần mềm
HUT, Falt. of IT Dept. of SE, 2002 SE-III.11
Sản phẩm (output) của “phát hiện yêu cầu phần mềm”
• Bảng kê (statement) các đòi hỏi và chức năng khả thi của phần mềm
• Bảng kê phạm vi ứng dụng của phần mềm • Mô tả môi trường kỹ thuật của phần mềm • Bảng kê tập hợp các kịch bản sử dụng của phần mềm • Các nguyên mẫu xây dựng, phát triển hay sử dụng trong phần mềm (nếu có)
• Danh sách nhân sự tham gia vào quá trình phát hiện các yêu cầu phần mềm - kể cả các nhân sự từ phía công ty- khách hàng
HUT, Falt. of IT Dept. of SE, 2002 SE-III.12
5.2.2. Phân tích các yêu cầu phần mềm và thương lượng với khách hàng
Software Engineering
Group Customer Group
HUT, Falt. of IT Dept. of SE, 2002 SE-III.13
Requirements Analysis and Negotiation • Phân loại các yêu cầu phần mềm và
sắp xếp chúng theo các nhóm liên quan
• Khảo sát tỉ mỉ từng yêu cầu phần mềm trong mối quan hệ của nó với các yêu cầu phần mềm khác
• Thẩm định từng yêu cầu phần mềm theo các tính chất: phù hợp, đầy đủ, rõ ràng, không trùng lặp
HUT, Falt. of IT Dept. of SE, 2002 SE-III.14
Requirements Analysis and Negotiation
• Phân cấp các yêu cầu phần mềm theo dựa trên nhu cầu và đòi hỏi khách hàng / người sử dụng
• Thẩm định từng yêu cầu phầm mềm để xác định chúng có khả năng thực hiện được trong môi trường kỹ thuật hay không, có khả năng kiểm định các yêu cầu phần mềm hay không
• Thẩm định các rủi ro có thể xảy ra với từng yêu cầu phần mềm
HUT, Falt. of IT Dept. of SE, 2002 SE-III.15
Requirements Analysis and Negotiation
• Đánh giá thô (tương đối) về giá thành và thời gian thực hiện của từng yêu cầu phần mềm trong giá thành sản phẩm phần mềm và thời gian thực hiện phần mềm
• Giải quyết tất cả các bất đồng về yêu cầu phần mềm với khách hàng / người sử dụng trên cơ sở thảo luận và thương lượng các yêu cầu đề ra
HUT, Falt. of IT Dept. of SE, 2002 SE-III.16
5.2.3. Đặc tả yêu cầu phần mềm • Đặc tả các yêu cầu phần mềm là công việc
xây dựng các tài liệu đặc tả, trong đó có thể sử dụng tới các công cụ như: mô hình hóa, mô hình toán học hình thức (a formal mathematical model), tập hợp các kịch bản sử dụng, các nguyên mẫu hoặc bất kỳ một tổ hợp các công cụ nói trên
• Chất lượng của hồ sơ đặc tả đánh giá qua các tiêu thức – Tính rõ ràng, chính xác – Tính phù hợp – Tính đầy đủ, hoàn thiện
HUT, Falt. of IT Dept. of SE, 2002 SE-III.17
Requirements Specification • Các thành phần của hồ sơ đặc tả
– Đặc tả phi hình thức (Informal specifications) được viết bằng ngôn ngữ tự nhiên
– Đặc tả hình thức (Formal specifications) được viết bằng tập các ký pháp có các quy định về cú pháp (syntax) và ý nghĩa (sematic) rất chặt chẽ
– Đặc tả vận hành chức năng (Operational specifications) mô tả các hoạt động của hệ thống phần mềm sẽ xây dựng
– Đặc tả mô tả (Descriptive specifications) – đặc tả các đặc tính đặc trưng của phần mềm
HUT, Falt. of IT Dept. of SE, 2002 SE-III.18
Requirements Specification
• Đặc tả chức năng (Operational Specifications): thông thường khi đặc tả các chức năng của phần mềm người ta sử dụng các công cụ tiêu biểu sau – Biểu đồ luồng dữ liệu (Data Flow Diagrams) – Máy trạng thái hữu hạn (Finite State
Machines – Mạng Petri (Petri nets)
HUT, Falt. of IT Dept. of SE, 2002 SE-III.19
Requirements Specification
• Đặc tả mô tả (Descriptive Specifications) – Biểu đồ thực thể liên kết (Entity-
Relationship Diagrams) –Đặc tả Logic (Logic Specifications) –Đặc tả đại số (Algebraic Specifications)
HUT, Falt. of IT Dept. of SE, 2002 SE-III.20
Biểu đồ luồng dữ liệu (DFD) • Hệ thống (System): tập hợp các dữ liệu
(data) được xử lý bằng các chức năng tương ứng (functions)
• Các ký pháp sử dụng: Thể hiện các chức năng (functions) Thể hiện luồng dữ liệu Kho dữ liệu Vào ra dữ liệu và tương tác giữa hệ thống và người sử dụng
HUT, Falt. of IT Dept. of SE, 2002 SE-III.21
Ví dụ mô tả biểu thức toán học bằng DFD
+
*
* +
b a a d
c
(a+b)*(c+a*d)
HUT, Falt. of IT Dept. of SE, 2002 SE-III.22
Ví dụ đặc tả các chức năng của thư viện qua DFD
Cã s¸ch
T×m theo chñ ®Ò
Yªu cÇu tõ ngêi mîn
Kho s¸ch
Danh s¸ch t¸c gi¶
Danh s¸ch tªn s¸ch
Danh s¸ch chñ ®Ò
Chñ ®Ò yªu cÇu §a ra Tªn s¸ch
Danh s¸ch ngêi mîn
Th«ng tin vÒ s¸ch
S¸ch
Chñ ®Ò
Tªn t¸c gi¶
Tªn s¸ch
LiÖt kª c¸c tªn s¸ch liªn quan ®Õn chñ ®Ò
Tªn s¸ch; Tªn ngêi mîn
S¸ch
Tªn s¸ch, t¸c gi¶ Tªn ngêi mîn
HUT, Falt. of IT Dept. of SE, 2002 SE-III.23
Các hạn chế của DFD • ý nghĩa của các ký pháp sử dụng được
xác định bởi các định danh lựa chọn của NSD Ví dụ của chức năng tìm kiếm: If NSD nhập vào cả tên tác giả và tiêu đề sách Then tìm kiếm sách tương ứng, không có thì thông báo lỗi Elseif chỉ nhập tên tác giả Then hiển thị danh sách các sách tương ứng với tên tác giả đã nhập và yêu cầu NSD lựa chọn sách Elseif chỉ nhập tiêu đề sách Then . . . Endif
HUT, Falt. of IT Dept. of SE, 2002 SE-III.24
• Trong DFD không xác định rõ các hướng thực hiện (control aspects)
Biểu đồ DFD này không chỉ rõ đầu vào
là gì để thực hiện chức năng D và đầu ra là gì sau khi thựchiện chức năng D.
A
B
C
D F
E
HUT, Falt. of IT Dept. of SE, 2002 SE-III.25
– Chức năng D có thể cần cả A, B và C – Chức năng D có thể chỉ cần một trong A, B
và C để thực hiện – Chức năng D có thể kết xuất kết quả cho một trong E và F
– Chức năng D có thể kết xuất kết quả chung cho cả E và F
– Chức năng D có thể kết xuất kết quả riêng cho cả E và F
A
B
C
D F
E
HUT, Falt. of IT Dept. of SE, 2002 SE-III.26
• DFD không xác định sự đồng bộ giữa các chức năng / mô-đun – A xử lý dữ liệu và B được hưởng (nhận)
các kết quả được xử lý từ A – A và B là các chức năng không đồng bộ
(asynchronous activities) vì thế cần có buffer để ngăn chặn tình trang mất dữ liệu
A B
HUT, Falt. of IT Dept. of SE, 2002 SE-III.27
Finite State Machines (FSM) FSM chứa • Tập hữu hạn các trạng thái Q • Tập hữu hạn các đầu vào I • Các chức năng chuyển tiếp
ON OFF
High pressure alarm
High temp. alarm
Restart
QIQ →×:δ
HUT, Falt. of IT Dept. of SE, 2002 SE-III.28
Đặc tả các yêu cầu phần mềm bằng FSM
• Xem xét ví dụ về thư viện với các giao dịch như sau: – Mượn sách / Trả sách – Thêm đầu sách / Loại bỏ đầu sách – Liệt kê danh sách các đầu sách theo tên
tác giả hay theo chủ đề – Tìm kiếm sách theo các yêu cầu của người mượn
– Tìm kiếm sách quá hạn trả, . . .
HUT, Falt. of IT Dept. of SE, 2002 SE-III.29
Đặc tả . . .
• Các yêu cầu đặc biệt của thư viện: –Độc giả không được mượn quá một số lượng sách nhất định, trong một thời gian nhất định
–Một số sách không được mượn về –Một số người không được mượn một số loại sách nào đó, . . .
HUT, Falt. of IT Dept. of SE, 2002 SE-III.30
Các đối tượng – Tên sách Mã quyển Nhân viên phục vụ Người mượn • Chúng ta cần có tập hợp (danh sách) các tiêu đề
sách, danh sách các tác giả cho từng quyển sách, danh sách các chủ đề liên quan của các quyển sách
• Ta có tập hợp các sách (mỗi đầu sách có thể có nhiều quyển sách trong thư viện). Mỗi quyển sách có thể có 1 trong 5 trạng thái sau:
• (AV) - Available được phép mượn, (CO) - (BR) - đã mượn (Check Out; Borrow), (L): Last, (R): Remove
HUT, Falt. of IT Dept. of SE, 2002 SE-III.31
• FSM đặc tả các trạng thái
CO AV BR
L R
ii. Có thể có hạn chế về số sách được mượn cho 1 nhóm độc giả hoặc mọi độc giả, . . .
HUT, Falt. of IT Dept. of SE, 2002 SE-III.32
Mô hình đặc tả : Mô hình thực thể liên kết
• Mô hình khái niệm cho phép đặc tả các yêu cầu logic của hệ thống, thường được sử dụng trong các hệ thống dữ liệu lớn
ER Model – Thực thể – Quan hệ – Thuộc tính
Biểu đồ thực thể
HUT, Falt. of IT Dept. of SE, 2002 SE-III.33
• Thực thể – tập hợp các thông tin liên quan cần được xử lý trong phần mềm
Thực thể có thể có mối quan hệ: – person owns car
Person Owns Car
HUT, Falt. of IT Dept. of SE, 2002 SE-III.34
• Thực thể có các thuộc tính • Thuộc tính: Tính chất của một thực thể hoặc một đối tượng dữ liệu – đặt tên cho 1 mẫu (instance) của đối tượng dữ liệu – mô tả mẫu (instance) – tạo liên kết (reference) đến các mẫu khác
Car
Ford
Blue
ID
Automobile Company
Ford
Tập các thuộc tính của 1 đối tượng dữ liệu được xác định thông qua ngữ cảnh của bài toán
HUT, Falt. of IT Dept. of SE, 2002 SE-III.35
• Quan hệ – chỉ ra mối liên quan gữa các đối tượng dữ liệu
Bookstore Orders Books 1 N
Cardinality : chỉ ra định lượng của mối quan hệ
1:1 one-to-one 1:N one-to-many M:N many-to-many
Modality : 0 – có thể có, có thể không có quan hệ
1 – bắt buộc có quan hệ
Customer Is
provided with
Repair Action 1 N
HUT, Falt. of IT Dept. of SE, 2002 SE-III.36
Ví dụ ERD mô tả thư viện Area
Title
Author
Deals with
Written by
Belongs to Copy
holds Was held by
Borrower
state
1 M
N N
N
Text
1
ER diagram for a library limit
HUT, Falt. of IT Dept. of SE, 2002 SE-III.37
Các yêu cầu của một đặc tả tốt • Đẽ hiểu với người dùng • Có ít điều nhập nhằng • Có ít quy ước khi mô tả, có thể tạo đơn giản • Với phong cách từ trên xuống (topdown) • Dễ triển khai cho những pha sau của vòng đời: thiết kế hệ thống và thiết kế chương trình và giao diện dễ làm, đảm bảo tính nhất quán, . . .
HUT, Falt. of IT Dept. of SE, 2002 SE-III.38
5.3. Các nguyên lý phân tích yêu cầu sử dụng
• Nguyên lý I. Mô hình hóa dữ liệu – Xác định các đối tượng dữ liệu – Xác định các đặc tính của các đối tượng dữ liệu
– Thiết lập các mối quan hệ giữa các đối tượng dữ liệu
HUT, Falt. of IT Dept. of SE, 2002 SE-III.39
Các nguyên lý phân tích yêu cầu sử dụng
• Nguyên lý II. Mô hình hóa các chức năng
– Xác định các chức năng chuyển đổi đối tượng dữ liệu
–Chỉ ra luồng dữ liệu đi qua hệ thống như thế nào
– Biểu diễn bộ phận sản sinh dữ liệu và bộ phận tiêu thụ dữ liệu
HUT, Falt. of IT Dept. of SE, 2002 SE-III.40
Các nguyên lý phân tích yêu cầu sử dụng
• Nguyên lý III. Mô hình hóa hành vi
–Chỉ ra các trạng thái (states) khác nhau của hệ thống
–Đặc tả các hiện tượng (events) làm hệ thống thay đổi trạng thái
HUT, Falt. of IT Dept. of SE, 2002 SE-III.41
Các nguyên lý phân tích yêu cầu sử dụng
• Nguyên lý IV. Partition the Models Tinh lọc từng mô hình để biểu diễn
các mức trừu tượng thấp hơn • Lọc đối tượng dữ liệu • Tạo ra phân cấp chức năng • Biểu diễn hành vi (behavior) ở các mức chi tiết khác nhau
HUT, Falt. of IT Dept. of SE, 2002 SE-III.42
Các nguyên lý phân tích yêu cầu sử dụng
• Nguyên lý V. Bản chất (Essence) Hãy bắt đầu bằng cách tập trung vào bản chất của vấn đề chứ không xem xét những chi tiết cài đặt (begin by focusing on the essence of the problem without regard to implementation details)
New Tool: Unified Modeling Language (UML)!
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.1
Nhập môn Công nghệ học Phần mềm
Introduction to Software Engineering
Department of Software Engineering Faculty of Information Technology
Hanoi University of Technology TEL: 04-8682595 FAX: 04-8692906
Email: [email protected]
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.2
Phần IV Thiết kế và Lập trình
Design and Programming
Chương 6: Phương pháp thiết kế hệ thống
6.1. Thiết kế hệ thống là gì? 6.2. Phương pháp thiết kế hệ thống
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.3
6.1. Thiết kế hệ thống là gì?
• Là thiết kế cấu hình phần cứng và cấu trúc phần mềm (gồm cả chức năng và dữ liệu) để có được hệ thống thỏa mãn các yêu cầu đề ra
• Có thể xem như Thiết kế cấu trúc (WHAT), chứ không phải là Thiết kế Logic (HOW)
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.4
Quy trình thiết kế hệ thống
• Phân chia mô hình phân tích ra các hệ con • Tìm ra sự tương tranh (concurrency)
trong hệ thống • Phân bố các hệ con cho các bộ xử lý hoặc
các nhiệm vụ (tasks) • Phát triển thiết kế giao diện • Chọn chiến lược cài đặt quản trị dữ liệu
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.5
Quy trình thiết kế hệ thống (tiếp)
• Tìm ra nguồn tài nguyên chung và cơ chế điều khiển truy nhập chúng
• Thiết kế cơ chế điều khiển thích hợp cho hệ thống, kể cả quản lý nhiệm vụ
• Xem xét các điều kiện biên được xử lý như thế nào
• Xét duyệt và xem xét các thỏa hiệp (trade-offs)
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.6
Các điểm lưu ý khi thiết kế hệ thống
(1) Có thể trích được luồng dữ liệu từ hệ thống: đó là phần nội dung đặc tả yêu cầu và giao diện
(2) Xem xét tối ưu tài nguyên kiến trúc lên hệ thống rồi quyết định kiến trúc
(3) Theo quá trình biến đổi dữ liệu, hãy xem những chức năng được kiến trúc như thế nào
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.7
Các điểm lưu ý (tiếp)
(4) Từ kiến trúc các chức năng theo (3), hãy xem xét và chỉnh lại, từ đó chuyển sang kiến trúc chương trình và thiết kế chi tiết
(5) Quyết định các đơn vị chương trình theo các chức năng của hệ phần mềm có dựa theo luồng dữ liệu và phân chia ra các thành phần
(6) Khi cấu trúc chương trình lớn quá, phải phân chia nhỏ hơn thành các môđun
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.8
Các điểm lưu ý (tiếp)
(7) Xem xét dữ liệu vào-ra và các tệp dùng chung của chương trình. Truy cập tệp tối ưu
(8) Hãy nghĩ xem để có được những thiết kế trên thì nên dùng phương pháp luận và những kỹ thuật gì ?
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.9
Thiết kế hệ thống
• Thiết kế hệ thống – Thiết kế hệ thống phần cứng [(1), (2)] – Thiết kế hệ thống phần mềm [(3)-(7)]
• Thiết kế hệ thống phần mềm – Thiết kế tệp (file design) [(7)] – Thiết kế chức năng hệ thống [(3)-(6)]
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.10
6.2 Phương pháp thiết kế hệ thống
• Phương pháp thiết kế cấu trúc hóa (Structured Design) của Constantine
• Ngoài ra còn các phương pháp khác, như Phương pháp thiết kế tổng hợp (Composite Design) của Myers
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.11
Thiết kế cấu trúc hóa
• Bắt nguồn từ modularity, top-down design, structured programming
• Còn xem như Phương pháp thiết kế hướng luồng dữ liệu (Data flow-oriented design)
• Quy trình 6 bước: (1) tạo kiểu luồng thông tin; (2) chỉ ra biên của luồng; (3) ánh xạ DFD sang cấu trúc chương trình; (4) xác định phân cấp điều khiển; (5) tinh lọc cấu trúc; (6) chọn mô tả kiến trúc
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.12
Thiết kế cấu trúc hóa
(1) Môđun và tham số (2) Lưu đồ bong bóng và cấu trúc phân cấp
Lưu đồ bong bóng (Bubble chart) Cấu trúc phân cấp (Hierarchical structured chart)
(3) Phương pháp phân chia STS (Source/Transform/Sink) và TR (Transaction)
(4) Phân tích cấu trúc hóa (5) Chuẩn phân chia môđun
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.13
(1) Môđun
• Dãy các lệnh nhằm thực hiện chức năng (function) nào đó
• Có thể được biên dịch độc lập • Môđun đã được dịch có thể được môđun
khác gọi tới • Giao diện giữa các môđun thông qua các biến tham số (arguments)
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.14
(2a) Lưu đồ bong bóng (Bubble chart)
• Biểu thị luồng xử lý dữ liệu • Ký pháp
Tên chức năng
Tên dữ liệu Tên dữ liệu
(Dữ liệu vào) (Dữ liệu ra) (Bong bóng)
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.15
(2b) Cấu trúc phân cấp (Hierarchical structured chart)
• Là phân cấp biểu thị quan hệ phụ thuộc giữa các môđun và giao diện (interface) giữa chúng
• Các quy ước: – Không liên quan đến trình tự gọi các môđun, nhưng ngầm định là từ trái qua phải
– Mỗi môđun xuất hiện trong cấu trúc 1 lần, có thể được gọi nhiều lần
– Quan hệ trên dưới: không cần nêu số lần gọi
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.16
Hierarchical structured chart
• Các quy ước (tiếp): – Tên môđun biểu thị chức năng (“làm gì”), đặt tên
sao cho các môđun ở phía dưới tổng hợp lại sẽ biểu thị đủ chức năng của môđun tương ứng phía trên
– Biến số (arguments) biểu thị giao diện giữa các môđun, biến số ở các môđun gọi/bịgọi có thể khác nhau
– Mũi tên với đuôi tròn trắng biểu thị dữ liệu, đuôi tròn đen (hồng) biểu thị flag
– Chiều của mũi tên là hướng truyền tham số
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.17
Hierarchical structured chart
Module A
Module B Module C Module D
Module E
1
Luồng dữ liệu
Luồng flag
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.18
(3) Phương pháp phân chia STS, TR
• Thiết kế cấu trúc: – Phương pháp phân chia STS
(Source/Transform/Sink: Nguồn/Biếnđổi/Hấpthụ)
– Phương pháp phân chia TR (Transaction) • Minh họa phân chia chức năng theo
bong bóng của DFD (biểu đồ luồng dữ liệu)
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.19
(3a) Phương pháp phân chia STS
1) Chia đối tượng “bài toán” thành các chức năng thành phần
Bài toán Problem
F1 F2
F3 F4
F5
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.20
Quyết định luồng dữ liệu chính
2) Tìm ra luồng dữ liệu chính đi qua các chức năng: từ đầu vào (Input) tới đầu ra (Output)
F1
F2
F3
F4 F5
INPUT
OUTPUT
Luồng dữ liệu chính
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.21
Quyết định bong bóng và dữ liệu
3) Theo luồng dữ liệu chính: thay từng chức năng bởi bong bóng và làm rõ dữ liệu giữa các bong bóng
F2 F3 F4 F5 F1 Data1 Data2 Data3 Data4 Data5 Data6
INPUT OUTPUT
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.22
Từ sơ đồ bong bóng sang sơ đồ phân cấp
4) Xác định vị trí trừu tượng hóa tối đa đầu vào và đầu ra
F2 F3 F4 F5 F1 Data1 Data2 Data3 Data4 Data5 Data6
INPUT OUTPUT Trừu tượng hóa tối đa đầu vào
Trừu tượng hóa tối đa đầu ra
Source Module Transform Module Sink Module
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.23
5) Chuyển sang sơ đồ phân cấp
F2 F3 F4 F5 F1 Data1 Data2 Data3 Data4 Data5 Data6
INPUT OUTPUT Trõu tîng hãa
tèi ®a ®Çu vµo Trõu tîng hãa tèi ®a ®Çu ra
Source Module Transform Module Sink Module
Control Module
Source Module
Transform Module
Sink Module
0
1 2 3
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.24
6) Xác định các tham số giữa các môđun dựa theo quan hệ phụ thuộc
Module 0
Module 1 Module 2 Module 3
0
1 2 3
3 3 5
5
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.25
7) Với từng môđun (Source, Transform, Sink) lại áp dụng cách phân chia STS lặp lại các bước từ 1) đến 6). Đôi khi có trường hợp không chia thành 3 mô đun nhỏ mà thành 2 hoặc 1
8) Tiếp tục chia đến mức cấu trúc lôgic khi môđun tương ứng với thuật toán đã biết thì dừng. Tổng hợp lại ta được cấu trúc phân cấp: mỗi nút là 1 môđun với số nhánh phía dưới không nhiều hơn 3
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.26
(3b) Phương pháp phân chia TR • Khi không tồn tại luồng dữ liệu chính, mà dữ liệu vào có đặc thù khác nhau như những nguồn khác nhau xem như các Giao dịch khác nhau
• Mỗi giao dịch ứng với 1 môđun xử lý nó • Phân chia môđun có thể: theo kinh nghiệm;
theo tính độc lập môđun; theo số bước tối đa trong 1 môđun (ví dụ < 50) và theo chuẩn
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.27
(4) Phân tích cấu trúc hóa
• Xác định luồng dữ liệu • Luồng tuyến tính thì theo phân chia STS • Luồng phân nhánh thì theo phân chia
TR
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.28
(5) Chuẩn phân chia môđun
• Tính độc lập: Độ kết hợp (coupling) và Độ bền vững (strength)
• 5 tiêu chuẩn của Myers – Decomposability – Composability – Understandability – Continuity – Protection
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.29
Đặc trưng của thiết kế cấu trúc hóa
• Dễ thích ứng với mô hình vòng đời thác nước do tính thân thiện cao
• Thiết kế theo tiến trình, không hợp với thiết kế xử lý theo lô (batch system)
• Dùng phân chia - kết hợp để giải quyết tính phức tạp của hệ thống
• Topdown trong phân chia môđun • Kỹ thuật lập trình hiệu quả
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.30
Chương 7: Kỹ thuật thiết kế chương trình
7.1 Thiết kế chương trình là gì ? 7.2 Phương pháp thiết kế chương trình 7.3 Công cụ thiết kế
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.31
7.1 Thiết kế chương trình là gì ?
• Là thiết kế chi tiết cấu trúc bên trong của phần mềm: thiết kế tính năng từng môđun và giao diện tương ứng
• Cấu trúc ngoài của phần mềm: thiết kế hệ thống
• Trình tự xử lý bên trong: Thuật toán (giải thuật, Algorithm); Logic
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.32
7.2 Phương pháp thiết kế chương trình
• Không có trạng thái mờ (fuzzy), để đảm bảo thiết kế cấu trúc trong đúng đắn
• Ngôn ngữ lập trình phù hợp • Triển khai đúng đắn đặc tả chức năng
các môđun và chương trình nhờ phương pháp luận thiết kế chi tiết
• Dùng quy trình thiết kế dễ chuẩn hóa từng bước
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.33
Kỹ thuật thiết kế chương trình
• Kỹ thuật thiết kế mô hình hệ phần mềm – Hướng tiến trình (process) : Kỹ thuật thiết kế cấu trúc điều khiển
– Hướng cấu trúc dữ liệu (data): Kỹ thuật thiết kế cấu trúc dữ liệu
– Hướng sự vật / đối tượng (object): Kỹ thuật thiết kế hướng đối tượng
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.34
7.2.1 Lập trình cấu trúc hóa • Khái niệm cơ bản: tuần tự, nhánh (chọn), lặp; cấu trúc mở rộng, tiền xử lý, hậu xử lý
• Những điểm lợi khi thiết kế thuật toán – Tính độc lập của môđun: chỉ quan tâm vào-
ra – Làm cho chương trình dễ hiểu – Dễ theo dõi chương trình thực hiện – Hệ phức tạp sẽ dễ hiểu nhờ tiếp cận phân cấp
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.35
Loại bỏ GOTO
• GOTO dùng để làm gì? – Cho phép thực hiện các bước nhảy đến một nhãn nhất định
• Tại sao cần loại bỏ GOTO ? – Phá vỡ tính cấu trúc của lập trình cấu trúc hóa
• Phương pháp loại bỏ GOTO • Có thể loại bỏ GOTO trong mọi trường hợp? • Thế nào là “kỹ năng lập trình cấu trúc”
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.36
Lưu ý khi thiết kế chương trình
• Phụ thuộc vào kỹ năng và kinh nghiệm của người thiết kế
• Cần chuẩn hóa tài liệu đặc tả thiết kế chi tiết
• Khi thiết kế cấu trúc điều khiển của giải thuật, vì theo các quy ước cấu trúc hóa nên đôi khi tính sáng tạo của người thiết kế bị hạn chế, bó buộc theo khuôn mẫu đã có
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.37
7.2.2 Lưu đồ cấu trúc hóa
• Tác dụng của lưu đồ (flow chart) • Quy phạm (discipline) • Trừu tượng hóa thủ tục • Lưu đồ cấu trúc hóa
– Cấu trúc điều khiển cơ bản – Chi tiết hóa từng bước giải thuật – Thể hiện được trình tự điều khiển thực hiện
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.38
Lưu đồ Nassi-Shneiderman (NS chart by IBM)
a- Nối (concatination) b- Chọn (selection)
c- Đa nhánh (CASE) d- Lặp (repetition)
Xử lý 1
Xử lý 2
ĐIều kiện Y N Xử lý 1 Xử lý 2
ĐIều kiện
Xử lý 1 Xử lý 2
Xử lý 3
TT1
TT2 TT3 DO WHILE (Đkiện)
Xử lý REPEAT UNTIL (Đkiện)
Xử lý
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.39
Lưu đồ Phân tích bài toán (PAD chart by Hitachi)
a- Nối (concatination) b- Chọn (selection)
c- Đa nhánh (CASE) d- Lặp (repetition)
WHILE Đkiện Xử lý
Xử lý 1
Xử lý 2
Xử lý 1
Xử lý 2
Điều kiện
Xử lý 1 Xử lý 2 Xử lý 3 Xử lý 4
TT1
TT2
TT3
TT4
Đ I ề u
k i ệ n
UNTIL Đkiện Xử lý
Trục chính
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.40
7.2.3 Về Phương pháp Giắc-sơn (Jackson’s method) • JSP: Jackson Structured Programming • Các ký pháp:
– Cơ sở (elementary) – Tuần tự (sequence) – Lặp – Rẽ nhánh
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.41
Trình tự thiết kế chung
• Thiết kế cấu trúc dữ liệu (Data step) • Thiết kế cấu trúc chương trình (Program
step) • Thiết kế thủ tục (Operation step) • Thiết kế đặc tả chương trình (Text step)
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.42
7.2.4 Về Phương pháp Wa-ny (Warnier’s method)
• Khái niệm chung • Trình tự thiết kế
– Thiết kế dữ liệu ra – Thiết kế dữ liệu vào – Thiết kế cấu trúc chương trình – Thiết kế lưu đồ – Thiết kế lệnh thủ tục – Thiết kế đặc tả chi tiết
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.43
Chương 8: Kỹ thuật lập trình
8.1 Lịch sử phát triển của ngôn ngữ lập
trình 8.2 Cấu trúc chương trình - Cấu trúc dữ liệu dễ hiểu - Cấu trúc thuật toán dễ hiểu 8.3 Các công cụ lập trình
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.44
8.1 Lịch sử ngôn ngữ lập trình • Các ngôn ngữ thế hệ thứ nhất:
– Ngôn ngữ lập trình mã máy (machine code) – Ngôn ngữ lập trình assembly
• Các ngôn ngữ thế thế thứ hai: – FOTRAN, COBOL, ALGOL, BASIC – Phát triển 1950-1970
• Các ngôn ngữ thế hệ thứ ba – Ngôn ngữ lập trình cấp cao vạn năng (cấu trúc) – Lập trình hướng đối tượng – Lập trình hướng suy diễn – logic
• Các ngôn ngữ thế hệ thứ tư – Truy vấn – Các ngôn ngữ hỗ trợ quyết định
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.45
8.2 Cấu trúc dữ liệu dễ hiểu
• Nên xác định tất cả các cấu trúc dữ liệu và các thao tác cần thực hiện trên từng cấu trúc dữ liệu
• Việc biểu diễn/khai báo các cấu trúc dữ liệu chỉ nên thực hiện ở những mô đun sử dụng trực tiếp dữ liệu
• Nên thiết lập và sử dụng từ điển dữ liệu khi thiết dữ liệu
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.46
Cấu trúc thuật toán dễ hiểu • Algorithm • Structured coding và 9 điểm lưu ý:
– Tuân theo quy cách lập trình – Một đầu vào, một đầu ra – Tránh GOTO, trừ khi phải ra khỏi lặp và dừng – Dùng comments hợp lý – Dùng tên biến có nghĩa, gợi nhớ – Cấu trúc lồng rõ ràng – Tránh dùng CASE / switch nhiều hoặc lồng nhau – Mã nguồn 1 chương trình / môđun nên viết trên 1 trang – Tránh viết nhiều lệnh trên 1 dòng
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.47
IF THEN / IF THEN ELSE
ĐK Công việc1
Công việc 2
=0
≠0 PASCAL if điều kiện then begin công việc 1 end; else begin công việc 2 end
Ngôn ngữ C
if (điều kiện)
{ công việc 1}
else
{công việc 2}
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.48
CASE / switch
Ngôn ngữ C switch (<bthức>) { case <gtrị1>: <việc1>;[break;] case <gtrị2>: <việc2>; [break;] case <gtrịN>: <việcN>; [break;] [default : <việcN+1>; [break;] ] }
PASCAL CASE <biểu thức> OF gtrị1: <việc 1>; gtrị2: <việc 2>; ........... gtrịN: <việc N>; ELSE <việc N+1>; END;
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.49
FOR TO / DOWNTO
Bắt đầu
KThúc
Biến điều khiển = Giá trị đầu
Biến điều khiển > Giá trị cuối
Thực hiện <Công việc>
Biến điều khiển = giá trị tiếp theo của biến điều khiển)
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.50
PASCAL
FOR biếnđkhiển := GTđầu TO GTCuối DO
begin
<việc>
end;
Ngôn ngữ C for ( [biểuthức1] ; [biểuthứcĐK]; [biểuthức2] ) { <việc>; } Đặc biệt: có các lệnh thoát break; continue; exit
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.51
DO WHILE
Bắt đầu
KThúc
Công việc
Biểu thức Logic Sai
Đúng
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.52
• Kiểm tra điều kiện trước khi thực hiện • Lỗi thường gặp: Lặp vô hạn
PASCAL While BiểuthứcBoolean DO begin <Công việc> end;
Ngôn ngữ C while (<biểuthứcĐK>) { <Công việc>; }
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.53
REPEAT UNTIL
Bắt đầu
Kthúc
Công việc
Biểu thức Logic Sai
Đúng
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.54
• Có sự khác nhau giữa hai ngôn ngữ?
PASCAL Repeat <Công việc> until Biểu_thức_Boolean;
Ngôn ngữ C do { <Công việc>; } while (<biểuthứcĐK>);
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.55
Chú thích trong chương trình • Tại sao cần đặt các chú thích trong chương
trình ? • Vị trí đặt các chú thích trong chương trình
– Thành phần/ Module – Lớp – Hàm/thủ tục – Các vị trí đặc biệt khác
• Một số quy định khi đặt chú thích: – Ngắn gọn – Gợi nhớ
HUT, Falt. of IT Dept. of SE, 2001 SE-IV.56
8.3 Các công cụ lập trình • Environments: DOS, WINDOWS,
UNIX/LINUX • Editors, Compilers, Linkers, Debuggers • TURBO C, PASCAL • MS C, Visual Basic, Visual C++, ASP • UNIX/LINUX: C/C++, gcc (Gnu C
Compiler) • JAVA, CGI, perl • C#, .NET
HUT, Falt. of IT Dept. of SE, 2001 SE-V.1
Nhập môn Công nghệ học Phần mềm
Introduction to Software Engineering
Department of Software Engineering Faculty of Information Technology
Hanoi University of Technology TEL: 04-8682595 FAX: 04-8692906
Email: [email protected]
HUT, Falt. of IT Dept. of SE, 2001 SE-V.2
Phần V Kiểm thử và Bảo trì
Test and Maintenance Chương 9: Phương pháp kiểm thử
9.1 Khái niệm kiểm thử 9.2 Phương pháp thử 9.3 Kỹ thuật thiết kế trưòng hợp thử 9.4 Phương pháp thử các môđun
HUT, Falt. of IT Dept. of SE, 2001 SE-V.3
9.1 Khái niệm kiểm thử Định nghĩa kiểm thử: • Là mấu chốt của đảm bảo chất lượng phần mềm
• Là tiến trình (và là nghệ thuật) nhằm phát hiện lỗi bằng việc xem xét lại đặc tả, thiết kế và mã hoá.
• Kiểm thử thành công là phát hiện ra lỗi; kiểm thử không phát hiện ra lỗi là kiểm thử dở (Sue A.Conger- The New SE)
HUT, Falt. of IT Dept. of SE, 2001 SE-V.4
Những khó khăn khi kiểm thử
• Nâng cao chất lượng phần mềm nhưng không vượt quá chất lượng khi thiết kế: chỉ phát hiện các lỗi tiềm tàng và sửa chúng
• Phát hiện lỗi bị hạn chế do thủ công là chính
• Dễ bị ảnh hưởng tâm lý khi kiểm thử • Khó đảm bảo tính đầy đủ của kiểm thử
HUT, Falt. of IT Dept. of SE, 2001 SE-V.5
6 điểm lưu ý khi kiểm thử
(1) Chất lượng phần mềm do khâu thiết kế quyết định là chủ yếu, chứ không phải khâu kiểm thử
(2) Tính dễ kiểm thử phụ thuộc vào cấu trúc chương trình
(3) Người kiểm thử và người phát triển nên khác nhau
HUT, Falt. of IT Dept. of SE, 2001 SE-V.6
6 điểm lưu ý khi kiểm thử (tiếp)
(4) Dữ liệu thử cho kết quả bình thường thì không có ý nghĩa nhiều, cần có những dữ liệu kiểm thử mà phát hiện ra lỗi (5) Khi thiết kế trường hợp thử, không chỉ dữ liệu kiểm thử nhập vào, mà phải thiết kế trước cả dữ liệu kết quả sẽ có (6) Khi phát sinh thêm trường hợp thử thì nên thử lại những trường hợp thử trướcđó để tránh ảnh hưởng lan truyền sóng
HUT, Falt. of IT Dept. of SE, 2001 SE-V.7
Tương ứng giữa vòng đời dự án và kiểm thử
Đối tượng và phạm vi
Đặc tả chức năng/ Thiết kế lô gíc
Thiết kế Vật lý
Cấu trúc CT và đặc tả môđun
Mã hoá môđun CT
Kiểm thử chấp nhận
Kiểm thử hệ thống
Kiểm tích hợp
Kiểm ĐVCT
Kiểm hồi quy
HUT, Falt. of IT Dept. of SE, 2001 SE-V.8
9.2 Phương pháp thử: thử tĩnh
• Kiểm thử trên bàn hay Kiểm thử tĩnh: giấy và bút trên bàn, kiểm tra logic, lần từng chi tiết ngay sau khi lập trình xong
• Đi xuyên suốt (walk through) • Thanh tra (inspection)
HUT, Falt. of IT Dept. of SE, 2001 SE-V.9
Kiểm thử trên máy
• Gỡ lỗi bằng máy (machine debug) hay kiểm thử động: Dùng máy chạy chương trình để điều tra trạng thái từng động tác của chương trình
• 9 bước của trình tự kiểm thử bằng máy
HUT, Falt. of IT Dept. of SE, 2001 SE-V.10
Trình tự kiểm thử bằng máy (1) Thiết kế trường hợp thử theo thử trên
bàn (2) Trường hợp thử phải có cả kết quả kỳ
vọng sẽ thu được (3) Dịch chương trình nguồn và tạo môđun
tải để thực hiện (4) Khi trường hợp thử có xử lý tệp vào-
ra, phải làm trước trên bàn việc xác định miền của các tệp
HUT, Falt. of IT Dept. of SE, 2001 SE-V.11
Trình tự kiểm thử bằng máy (tiếp)
(5) Nhập dữ liệu đã thiết kế cho trường hợp kiểm thử
(6) Điều chỉnh môi trường thực hiện môđun tải (tạo thủ tục đưa các tệp truy cập tệp vào chương trình)
(7) Thực hiện môđun tải và ghi nhận kết quả (8) Xác nhận kết quả với kết quả kỳ vọng (9) Lặp lại thao tác (5)-(8)
HUT, Falt. of IT Dept. of SE, 2001 SE-V.12
9.3 Kỹ thuật thiết kế trường hợp thử
• Kỹ thuật thiết kế trường hợp thử dựa trên đặc tả bề ngoài của chương trình: Kiểm thử hộp đen (Black box test): WHAT ?
• Kỹ thuật thiết kế trường hợp thử dựa trên đặc tả bên trong của chương trình: Kiểm thử hộp trắng (white box test): HOW ?
• Kiểm thử Top-Down hay Bottom-Up
HUT, Falt. of IT Dept. of SE, 2001 SE-V.13
Kiểm thử hộp đen
• Phân đoạn tương đương • Phân tích giá trị biên • Đoán lỗi
Black Box Results Input
Black box Data Testing Strategy
HUT, Falt. of IT Dept. of SE, 2001 SE-V.14
Phương pháp phân đoạn tương đương (Equivalence Partition)
• Mục đích: giảm số lượng test bằng cách chọn các tập dữ liệu đại diện
• Thực hiện: Chia dữ kiệu vào thành các đoạn, mỗi đoạn đại diện cho một số dữ liệu => việc kiểm thử chỉ thực hiện trên đại diện đó
• ưu điểm: Test theo mức trừu tượng hơn là trường. áp dụng: màn hình, menu hay mức quá trình
HUT, Falt. of IT Dept. of SE, 2001 SE-V.15
Phương pháp phân tích giá trị biên (Boundary value analysis)
• Là 1 trường hợp riêng của phân đoạn • Thí dụ: nếu miền dữ liệu là tháng thì giá trị 0 hay >12 là không hợp lệ
• Thường sử dụng trong kiểm thử môđun
HUT, Falt. of IT Dept. of SE, 2001 SE-V.16
• Dựa vào trực giác và kinh nghiệm • Thí dụ lỗi chia cho 0. Nếu môđun có
phép chia thì phải kiểm thử lỗi này • Nhược điểm: không phát hiện hết lỗi
Phương pháp đoán lỗi (Error Guessing)
HUT, Falt. of IT Dept. of SE, 2001 SE-V.17
Phương pháp đồ thị nguyên nhân - kết quả (Cause-effect Graphing)
Mã tuần tự Phủ định and Or Do
Until
HUT, Falt. of IT Dept. of SE, 2001 SE-V.18
Kiểm thử hộp trắng
• Bó các lệnh • Bó các rẽ nhánh • Bó các điều kiện • Bó các điều kiện - rẽ nhánh
Results Input
White Box Data Testing Strategy
HUT, Falt. of IT Dept. of SE, 2001 SE-V.19
Trình tự thiết kế
• Kiểm thử môđun • Kiểm thử tích hợp - Kiểm thử tích hợp trên xuống - Kiểm thử tích hợp dưới lên - Kiểm thử hồi qui
HUT, Falt. of IT Dept. of SE, 2001 SE-V.20
9.4 Kỹ thuật kiểm thử môđun
• Kiểm thử tích hợp môđun – Kiểm thử dưới lên (Bottom-up Test) – Kiểm thử trên xuống (Top-down Test) – Kiểm thử cột trụ (Big bung Test) – Kiểm thử kẹp (Sandwich Test)
HUT, Falt. of IT Dept. of SE, 2001 SE-V.21
Bottom-up Test
• Các môđun mức thấp được tổ hợp vào các chùm thực hiện một chức năng con
• Viết trình điều khiển phối hợp vào/ ra và kiểm thử
• Kiểm thử chùm/bó • Loại bỏ trình điều khiển và chuyển lên mức trên
HUT, Falt. of IT Dept. of SE, 2001 SE-V.22
Bottom-up Test (Tiếp)
Mức 4
Mức 3
Mức 2
Mức 1
HUT, Falt. of IT Dept. of SE, 2001 SE-V.23
Top-down Test • Môđun điều khiển chính được dùng như
trình điều khiển kiểm thử, gắn các nút con trực tiếp vào nó
• Thay các nút con bằng các môđun thực tại (theo chiều sâu / ngang)
• Kiểm thử từng môđun được gắn vào • Các 1 nút thử xong được thử tiếp nút khác • Kiểm thử hồi quy
HUT, Falt. of IT Dept. of SE, 2001 SE-V.24
Top-down Test (tiếp)
Mức 1
Mức 2
Mức 3
Mức 4
HUT, Falt. of IT Dept. of SE, 2001 SE-V.25
Big bung Test
• Tích hợp không tăng dần • Tất các các môđun đều được tổ hợp trước
• Toàn bộ chương trình được kiểm thử tổng thể
• Khó khăn: khó cô lập lỗi, khi chữa xong lỗi này có thể lỗi mới lại phát sinh
HUT, Falt. of IT Dept. of SE, 2001 SE-V.26
Sandwich Test
• Tích hợp trên xuống cho các mức trên cấu trúc chương trình
• Tích hợp dưới lên cho các mức phụ thuộc
HUT, Falt. of IT Dept. of SE, 2001 SE-V.27
Kiểm thử hệ thống
• Kiểm thử phục hồi: bắt buộc phần mềm hỏng nhiều cách để kiểm chứng phục hồi
• Kiểm thử an toàn: kiểm chứng cơ chế bảo vệ
• Kiểm thử gay cấn • Kiểm thử hiệu năng
HUT, Falt. of IT Dept. of SE, 2001 SE-V.28
Chương 10: Phương pháp bảo trì
Maintenance Methods
10.1 Bảo trì là gì? 10.2 Trình tự nghiệp vụ bảo trì 10.3 Những vấn đề về bảo trì hiện nay
HUT, Falt. of IT Dept. of SE, 2001 SE-V.29
10.1 Bảo trì là gì? • Định nghĩa: Bảo trì là công việc tu sửa, thay đổi phần mềm đã được phát triển (chương trình, dữ liệu, JCL, các loại tư liệu đặc tả, . . .) theo những lý do nào đó
• Các hình thái bảo trì: bảo trì để – Tu chỉnh – Thích hợp – Cải tiến – Phòng ngừa
HUT, Falt. of IT Dept. of SE, 2001 SE-V.30
Bảo trì để tu sửa
• Là bảo trì khắc phục những khiếm khuyết có trong phần mềm
• Một số nguyên nhân điển hình – Kỹ sư phần mềm và khách hiểu nhầm nhau – Lỗi tiềm ẩn của phần mềm do sơ ý của lập trình hoặc
khi kiểm thử chưa bao quát hết – Vấn đề tính năng của phần mềm: không đáp ứng được
yêu cầu về bộ nhớ, tệp, . . . Thiết kế sai, biên tập sai . . .
– Thiếu chuẩn hóa trong phát triển phần mềm (trước đó)
HUT, Falt. of IT Dept. of SE, 2001 SE-V.31
Bảo trì để tu sửa (tiếp)
• Kỹ nghệ ngược (Reverse Engineering): dò lại thiết kế để tu sửa
• Những lưu ý – Mức trừu tượng – Tính đầy đủ – Tính tương tác – Tính định hướng
HUT, Falt. of IT Dept. of SE, 2001 SE-V.32
Bảo trì để thích hợp • Là tu chỉnh phần mềm theo thay đổi của môi trường bên ngoài nhằm duy trì và quản lý phần mềm theo vòng đời của nó
• Thay đổi phần mềm thích nghi với môi trường: công nghệ phần cứng, môi trường phần mềm
• Những nguyên nhân chính: – Thay đổi về phần cứng (ngoại vi, máy chủ,. . .) – Thay đổi về phần mềm (môi trường): đổi OS – Thay đổi cấu trúc tệp hoặc mở rộng CSDL
HUT, Falt. of IT Dept. of SE, 2001 SE-V.33
Bảo trì để cải tiến
• Là việc tu chỉnh hệ phần mềm theo các yêu cầu ngày càng hoàn thiện hơn, đầy đủ hơn, hợp lý hơn
• Những nguyên nhân chính: – Do muốn nâng cao hiệu suất nên thường hay cải tiến phương thức truy cập tệp
– Mở rộng thêm chức năng mới cho hệ thống – Cải tiến quản lý kéo theo cải tiến tư liệu vận hành và
trình tự công việc – Thay đổi người dùng hoặc thay đổi thao tác
HUT, Falt. of IT Dept. of SE, 2001 SE-V.34
Bảo trì để cải tiến (tiếp)
• Còn gọi là tái kỹ nghệ (re-engineering) • Mục đích: đưa ra một thiết kế cùng chức năng nhưng có chất lượng cao hơn
• Các bước thực hiện: – Xây dựng lưu đồ phần mềm – Suy dẫn ra biểu thức Bun cho từng dãy xử lý – Biên dịch bảng chân lí – Tái cấu trúc phần mềm
HUT, Falt. of IT Dept. of SE, 2001 SE-V.35
Bảo trì để phòng ngừa
• Là công việc tu chỉnh chương trình có tính đến tương lai của phần mềm đó sẽ mở rộng và thay đổi như thế nào
• Thực ra trong khi thiết kế phần mềm đã phải tính đến tính mở rộng của nó, nên thực tế ít khi ta gặp bảo trì phòng ngừa nếu như phần mềm được thiết kế tốt
HUT, Falt. of IT Dept. of SE, 2001 SE-V.36
Bảo trì để phòng ngừa (tiếp)
• Mục đích: sửa đổi để thích hợp với yêu cầu thay đổi sẽ có của người dùng
• Thực hiện những thay đổi trên thiết kế không tường minh
• Hiểu hoạt động bên trong chương trình • Thiết kế / lập trình lại • Sử dụng công cụ CASE
HUT, Falt. of IT Dept. of SE, 2001 SE-V.37
10.2 Trình tự nghiệp vụ bảo trì
• Quy trình bảo trì là gì ? Đó là quá trình trong vòng đời của phần mềm, cũng tuân theo các pha phân tích, thiết kế, phát triển và kiểm thử từ khi phát sinh vấn đề cho đến khi giải quyết xong
• Thao tác bảo trì: Gồm 2 loại – Tu chỉnh cải đã có (loại 1) – Thêm cái mới (loại 2)
HUT, Falt. of IT Dept. of SE, 2001 SE-V.38
Sơ đồ bảo trì Hiểu phần mềm đã có
Loại bảo trì?
Chỉnh phần mềm đã có
Kiểm thử tính nhất quán
Kiểm thử sau bảo trì
Tạo biểu quản lý bảo trì
Phát triển phần mềm mới 2
1
HUT, Falt. of IT Dept. of SE, 2001 SE-V.39
Hiểu phần mềm đã có
• Theo tài liệu nắm chắc các chức năng • Theo tài liệu chi tiết hãy nắm vững đặc tả
chi tiết, điều kiện kiểm thử, . . . • Dò đọc chương trình nguồn, hiểu trình tự xử lý chi tiết của hệ thống
3 việc trên đều là công việc thực thi trên bàn
HUT, Falt. of IT Dept. of SE, 2001 SE-V.40
Tu sửa phần mềm đã có
• Bảo trì chương trình nguồn, tạo các môđun mới và dịch lại
• Thực hiện kiểm thử unit và tu chỉnh những mục liên quan có trong tư liệu đặc tả
• Chú ý theo sát tác động của môđun được sửa đến các thành phần khác trong hệ thống
HUT, Falt. of IT Dept. of SE, 2001 SE-V.41
Phát triển phần mềm mới
• Khi thêm chức năng mới phải phát triển chương trình cho phù hợp với yêu cầu
• Cần tiến hành từ thiết kế, lập trình, gỡ lỗi và kiểm thử unit
• Phản ảnh vào giao diện của phần mềm (thông báo, phiên bản, . . .)
HUT, Falt. of IT Dept. of SE, 2001 SE-V.42
Kiểm chứng tính nhất quán bằng kiểm thử kết hợp
• Đưa đơn vị (unit) đã dược kiểm thử vào hoạt động trong hệ thống
• Điều chỉnh sự tương tích giữa các môđun • Dùng các dữ liệu trước đây khi kiểm thử để kiểm thử lại tính nhất quán
• Chú ý hiệu ứng làn sóng trong chỉnh sửa
HUT, Falt. of IT Dept. of SE, 2001 SE-V.43
Kiểm tra khi hoàn thành bảo trì
• Kiểm tra nội dung mô tả có trong tư liệu đặc tả
• Cách ghi tư liệu có phù hợp với mô tả môi trường phần mềm mới hay không ?
HUT, Falt. of IT Dept. of SE, 2001 SE-V.44
Lập biểu quản lý bảo trì
• Cần quản lý tình trạng bảo trì • Lập biểu quản lý tình trạng bảo trì
– Ngày tháng, giờ – Nguyên nhân – Tóm tắt cách khắc phục – Chi tiết khắc phục, hiệu ứng làn sóng – Người làm bảo trì – Số công
HUT, Falt. of IT Dept. of SE, 2001 SE-V.45
10.3 Những vấn đề lưu ý để bảo trì
Phương pháp cải tiến thao tác bảo trì: • Sáng kiến trong quy trình phát triển phần mềm
• Sáng kiến trong quy trình bảo trì phần mềm
• Phát triển những kỹ thuật mới cho bảo trì
HUT, Falt. of IT Dept. of SE, 2001 SE-V.46
Sáng kiến trong quy trình phát triển phần mềm
(1) Chuẩn hóa mọi khâu trong phát triển phần mềm
(2) Người bảo trì chủ chốt tham gia vào giai đoạn phân tích và thiết kế
(3) Thiết kế để dễ bảo trì
HUT, Falt. of IT Dept. of SE, 2001 SE-V.47
Sáng kiến trong quy trình bảo trì phần mềm
(1) Sử dụng các công cụ hỗ trợ phát triển phần mềm
(2) Chuẩn hóa thao tác bảo trì và thiết bị môi trường bảo trì
(3) Lưu lại những thông tin sử bảo trì (4) Dự án nên cử một người chủ chốt của
mình làm công việc bảo trì sau khi dự án kết thưc giai đoạn phát triển
HUT, Falt. of IT Dept. of SE, 2001 SE-V.48
Phát triển những kỹ thuật mới cho bảo trì
• Công cụ phần mềm hỗ trợ bảo trì • Cơ sở dữ liệu cho bảo trì • Quản lý tài liệu, quản lý dữ liệu, quản lý chương trình nguồn, quản lý dữ liệu thử, quản lý sử bảo trì
• Trạm bảo trì tính năng cao trong hệ thống mạng lưới bảo trì với máy chủ thông minh
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.1
Nhập môn Công nghệ học Phần mềm
Introduction to Software Engineering
Department of Software Engineering Faculty of Information Technology
Hanoi University of Technology TEL: 04-8682595 FAX: 04-8692906
Email: [email protected]
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.2
Phần VI Chương 11
Các chủ đề khác trong SE • ước lượng chi phí phần mềm (SE Cost
Estimation) • Quản lý chất lượng (Quality Management) • Cải tiến quá trình (Process Improvement) • Các chủ đề tiên tiến khác (Advanced
topics)
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.3
I. ước lượng chi phí phần mềm (SE Cost Estimation)
1) Năng suất (Productivity) 2) Các kỹ thuật ước đoán (Estimation
Techniques) 3) Mô hình chi phí thuật toán (Algorithmic
Cost Model) 4) Nhân lực và thời gian dự án (Project
duration and staffing)
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.4
Năng suất (Productivity)
• Năng suất là số đơn vị đầu ra trên số giờ làm việc
• Trong SE, năng suất có thể ước lượng bởi một số thuộc tính chia cho tổng số nỗ lực để phát triển:
- Số đo kích thước (thí dụ số dòng lệnh) - Số đo chức năng (số chức năng tạo ra trên
1 khoảng thời gian )
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.5
Các kỹ thuật ước đoán (Estimation Techniques)
• Mô hình chi phí thuật toán: sử dụng các thông tin có tính lịch sử (thường là kích thước)
• ý kiến chuyên gia • Đánh giá tương tự: chỉ áp dụng khi có nhiều dự án trong cùng một lĩnh vực
• Luật Parkinson: chi phí phụ thuộc thời gian và số nhân công
• Giá để thắng thầu: phụ thuộc khả năng KH
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.6
Mô hình chi phí thuật toán (Algorithmic Cost Model)
• Nguyên tắc: Dùng một phương trình toán học để dự đoán (Kitchenham 1990a) dạng:
Cố gắng = C x PMs x M với: - C là độ phức tạp - PM là số đo năng suất - M là hệ số phụ thuộc và quá trình, năng suất - s được chọn gần với 1, phản ánh độ gia tăng
của yêu cầu với các dự án lớn
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.7
Chú ý: - Rất khó dự đoán PM vào giai đoạn đầu - Việc dự đoán C và M là khách quan và có thể
thay đổi từ người này sang người khác. 1) Mô hình COCOMO (Boehm 1981): Mô hình
COCOMO tuân theo PT trên, với các lựa chọn sau: - Đơn giản: PM = 2,4 (KDSI)1,05 x M - Khiêm tốn: PM = 3,0 (KDSI)1,12 x M - Lồng nhau: PM = 3,6 (KDSI)1,20 x M với KDSI là số lệnh nguồn theo đơn vị nghìn
Mô hình chi phí thuật toán (tiếp)
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.8
2) Mô hình định cỡ (calibrate model): sử dụng một mô hình ước đoán có hiệu quả, do vậy cần có 1 CSDL về phân lịch và các cố gắng của một dự án trọn vẹn.
Nó có thể dùng kết hợp với mô hình COCOMO 3) mô hình chi phí thuật toán trong lập kế hoạch dự
án - Có thể dùng để đánh giá chi phí đầu tư nhằm giảm
chi phí - có 3 thành phần phải xem xét trong khi tính chi
phí DA.
Mô hình chi phí thuật toán (tiếp)
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.9
(1) Chi phí phần cứng của HT (2) Chi phí phương tiện, thiết bị (máy tính, phần mềm)
trong phát triển HT (3) Chi phí của các nỗ lực yêu cầu Chi phí phần mềm (Software Cost) được tính: SC = Basic Cost x RELY x TIME x STOR x TOOL x
EXP x lương TB 1 người/tháng với: STOR là không gian lưu trữ, TIME là thời gian cần thiết, TOOL là công cụ, EXP là kinh nghiệm, RELY là độ tin cậy (có thể chọn là 1,2)
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.10
Nhân lực và thời gian dự án (Project duration and staffing)
• Mô hình COCOMO cũng dự đoán lịch cho một DA trọn vẹn:
- Dự án đơn giản: TDEV = 2.5 (PM)0.38
- Dự án trung bình: TDEV = 2.5 (PM)0.35
- Dự án lồng: TDEV = 2.5 (PM)0.32
với TDEV là tổng thời gian cần thiết cho một DA
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.11
II.Quản lý chất lượng (Quality Management)
1) Đảm bảo chất lượng quá trình 2) Xem xét lại chất lượng 3) Các chuẩn phần mềm 4) Các chuẩn tài liệu 5) Độ đo phần mềm 6) Độ đo chất lượng sản phẩm
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.12
Đảm bảo chất lượng quy trình • Đảm bảo chất lượng quy trình là một khái niệm đa chiều. chưa có định nghĩa rõ ràng. Nhìn chung khái niệm này có thể xem như là phát triển SP phải đáp ứng được đặc tả của nó (Crossby, 1979)
Đặc tả phải hướng về đặc trưng SP mà KH muốn Chúng ta không biết đặc tả thế nào về chất lượng Đặc tả phần mềm luôn luôn không đầy đủ
• Quản lý chất lượng là đáp ứng 3 loại hoạt động sau: Đảm bảo chất lượng Kế hoạch chất lượng: chọn thủ tục tương ứng, chuẩn và kích thước
Điều khiển chất lượng: các thủ tục và chuẩn phải được tôn trọng
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.13
Đảm bảo chất lượng quy trình(tiếp)
Định nghĩa Quá trình
Phát triển sản phẩm
KĐ chất lượng sản phẩm
Quá trình cải tiến
Chất lượng Quá trình chuẩn hoá
C
K
Chất lượng dựa vào quá trình
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.14
Xem xét lại chất lượng
• Là phương pháp chính để khẳng định chất lượng của quá trình sản xuất
• 3 kiểu xem xét: - Thanh tra thiết kế hay chương trình - Xem xét tiến triển - Xem xét chất lượng
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.15
Xem xét lại chất lượng (tiếp)
Lựa chọn đội ngũ
Sắp xếp vị trí và thời gian
Phân bố tài liệu
Xem xét
xem xét đầy đủ
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.16
Các chuẩn phần mềm • Vai trò quan trọng của ĐBCLPM là
chuẩn hoá các sản phẩm và quá trình • Tầm quan trọng:
Cung cấp SP tương ứng và thực tế Cung cấp các framework để cài đặt cá quá trình ĐBCL Đảm bảo tính liên tục: công việc thực hiện bởi 1 người có thể thực hiện tiếp bởi người khác
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.17
Độ đo phần mềm (Software Metric)
• Độ đo phần mềm là một kiểu độ đo liên quan đến HT phần mềm, quá trình hay TL, Thí dụ như số dòng lệnh, số thông báo lỗi khi cung cấp SP
• Hai lớp độ đo: Độ đo ĐK và độ đo dự đoán
Quá trình PM Sản phẩm PM
Độ đo ĐK Độ đo Dự đoán
Các quyết định QL
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.18
Các chuẩn tài liệu
• Tài liệu là 1 phần quan trọng trong SE để theo dõi, để hiểu và để làm
• 3 kiểu chuẩn tài liệu: – Các chuẩn của quá trình lập tài liệu: Qui định chuẩn khi tạo tài liệu
– Chuẩn TL: Chuẩn để quản trị chính TL đó – Chuẩn trao đổi TL: Dùng trong trao đổi qua
E-mail, copy hay lưu trữ trong CSDL
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.19
Độ đo chất lượng SP
• Việc biểu diễn, đánh giá độ đo bằng các số liệu hơn là kinh nghiệm
• Độ đo chất lượng TK (xem chất lượng TK trong phần IV: tính liên kết, độ liên kết, dễ hiểu và thích hợp)
• Độ đo chất lượng CT: chiều dài mã, độ phức tạp, mức lồng điều kiện, . . .
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.20
III. Cải tiến Quy trình (Process Improvement)
• Chất lượng quy trình và sản phẩm • Mô hình hoá và phân tích quy trình • Độ đo • Mô hình thuần thục khả năng SEI • Phân loại quy trình
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.21
• Cải tiến quy trình có nghĩa hiểu quy trình tồn tại và thay đổi quy trình này để nâng cao chất lượng SP hay giảm chi phí & thời gian phát triển
• Không đơn giản là chấp nhận 1 phương pháp hay công cụ đặc biệt nào hay sử dụng 1 mô hình quy trình đã sử đâu đó
• Quá trình Cải tiến quy trình phải được xem xét như 1 hoạt động đặc biệt trong 1 tổ chức hoặc 1 phần của tổ chức lớn
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.22
Sơ đồ khái quát của Quá trình cải tiến quy trình
Phân tích Quy trình
Xác định Các cải tiến
Xác định các thay đổi
Đào tạo đội ngũ
Hiệu chỉnh Các thay đổi
Mô hình Quy trình
Lập kế hoạch
Kế hoạch đào tạo
Mô hình xem xét lại Phản hồi
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.23
Quá trình cải tiến quy trình (tiếp) • Phân tích quy trình: xem xét quy trình đã tồn tại, tạo ra mô hình quy trình để lập TL và hiểu quy trình đó
• Xác định cải tiến: sử dụng kết quả phân tích để xác định chất lượng, lập lịch hay chi phí những pha gay cấn
• Xác định thay đổi: Thiết lập các thủ tục, phương pháp, công cụ mới và tích hợp với các cái đã tồn tại
• Đào tạo: không đào tạo quy trình sẽ thất bại • Hiệu chỉnh thay đổi: các thay đổi có tác dụng ngay với HT
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.24
• Xem chương trước
Chất lượng quy trình và sản phẩm
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.25
Mô hình hoá và phân tích quy trình • Vai trò: nghiên cứu các quy trình đang tồn tại và
phát triển mô hình trừu tượng cho các quy trình này (thâu tóm các đặc trưng)
• Phân tích là nghiên cứu để hiểu mối liên quan giữa các phần của quy trình. Điểm xuất phát là mô hình hình thức đã sử dụng
• Kỹ thuật: Hỏi và phỏng vấn Kỹ thuật Ethnographic: dùng để hiểu bản chất của phát triển phần mềm như các hoạt động của con người
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.26
Mô hình hoá (tiếp) Các ký pháp dùng trong mô hình: Activity (hoạt động): biểu diễn bởi hình chữ nhật tròn Process (quá trình): tập các hoạt động, biểu diễn bởi hình chữ nhật tròn có bóng mờ Deliverable (phân phối): biểu diễn bởi 1
hình chữ nhật có bóng mờ. Nó là đầu ra của 1 hoạt động Condition (điều kiện): biểu diễn bởi 1 hình chữ nhật. Nó là tiền hay hậu điều kiện Role (vai trò): biểu diễn bởi hình tròn
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.27
Mô hình hoá (tiếp)
Exception (Ngoại lệ): Hộp bao kép. Việc thay đổi do một sự kiện nào đó Communication (Giao tiếp): Biểu diễn bởi Trao đổi thông tin giữa con người với nhau
hay với HT
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.28
Độ đo quy trình • Độ đo của 1 quy trình là các dữ liệu định lượng về quy trình phần mềm (Tập các độ đo là chủ yếu cho quá trình cải tiến quy trình –Humphey, 1989).
• Phân loại: – Thời gian để thực hiện 1 quy trình đặc biệt – Tài nguyên yêu cầu cho 1 quy trình đặc biệt – Số các biến cố
• Khó khăn: Cái nào là cần định lượng đo đếm. Tuy nhiên có thể xem: mục đích (Goals, Câu hỏi, Độ đo)
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.29
Mô hình thuần thục khả năng (của SEI)
• Viện CNPM (SEI) Carnegie-Melon-University đề xuất. Mô hình SEI phân quá trình phần mềm thành 5 mức khác nhau: Mức khởi đầu: 1 tổ chức không quản lý thực sự các thủ tục hay DA. Phần mềm có thể phát triển song không thể dự đoán trước (ngân sách, thời gian, . . .)
Mức lặp: 1 tổ chức có thể có quản lý hình thức về đảm bảo chất lượng, các thủ tục điều khiển cấu hình. Tổ chức có thể lặp lại các DA cùng kiểu
Mức có định nghĩa: ở mức này, một tổ chức có định nghĩa các qua trình của mình mà như vậy có 1 cơ sở cho quá trình cải tiến chất lượng. Các thủ tục hình thức đảm bảo rằng các quá trình đã định là sẽ được tuân thủ
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.30
Mô hình thuần thục khả năng SEI (tiếp)
Mức được quản trị: 1 tổ chức đã định nghĩa các quá trình và 1 CT để thu thập dữ liệu về chất lượng. Số đo quá trình và thủ rục được sưu tập cho quá các hoạt động của quá trình cải tiến
Mức tối ưu: Đã thoả thuận tiếp tục quá trình cải tiến. Quá trình này có ngân sách và kế hoạch để thực hiện và là phần tích hợp của quá trình tổ chức
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.31
Phân loại quy trình
• Việc phân loại độ chín của các quy trình như trên thường áp dụng cho các DA lớn
• Phân loại: Quy trình không hình thức : các quá trình mà
mô hình không định nghĩa 1 cách chặt chẽ Quy trình được quản lý: mô hình quá trình được định nghĩa (định hướng) Quy trình có phương pháp: một số phương
pháp phát triển đã được định nghĩa Quy trình cải tiến:
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.32
IV. Các chủ đề tiên tiến khác • Phương pháp hình thức (Formal methods) • Công nghệ học phần mềm phòng sạch
(Cleanroom SE) • CNHPM hướng thành phần (CBSE) • CNHPM khách/chủ (Client/Server SE) • Kỹ nghệ Web (Web Engineering) • Tái kỹ nghệ (Re-engineering) • CNHPM dựa trên máy tính (CASE) (Chi tiết xem trong các tài liệu)
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.33
• Dịch chuyển mã nguồn
• Cấu trúc lại CT • Tái lập DL • Kỹ nghệ ngược
Tái kỹ nghệ phần mềm (Software Re-engineering)
HUT, Falt. of IT Dept. of SE, 2001 SE-VI.34
Phát triển và tái kỹ nghệ
Đặc tả hệ thống Thiết kế và Cài đặt Hệ thống mới
Forward Engineering
Hệ thống đang tồn tại
Hiểu và dịch chuyển Hệ thống
Hệ thống được tái tạo
Software Re-engineering