Tài liệu Nhập môn công nghệ phần mềm
Tài liệu Nhập môn công nghệ phần mềm. Tài liệu được sưu tầm. Mời các bạn tham khảo
Môn: Nhập môn công nghệ phần mềm (UET) 3 tài liệu
Trường: Trường Đại học Công nghệ, Đại học Quốc gia Hà Nội 816 tài liệu
Tác giả:
Preview text:
Nhập môn Phần I
Giới thiệu chung về CNHPM
Công nghệ học Phần mềm
(Introduction to Software Engineering)
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 Cấu trúc môn học 1.3 Các khái niệm
• 45 tiết + 1 Đồ án môn học 1.4
Đặc tính chung của phần mềm
• Cần những kiến thức căn bản về CNTT 1.5
Thế nào là phần mềm tốt ?
• Cung cấp những nguyên lý chung về Công nghệ học Phần mềm (CNHPM)
1.6 Các ứng dụng phần mềm
• 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,...
1.1. Định nghĩa chung về phần mềm
• Nội dung: gồm 6 phần với 11 chương
• 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,
– Giới thiệu chung về CNHPM (3 buổi)
đây là 2 khái niệm tương đối
– Quản lý dự án PM (2b)
• Từ xưa, SW như thứ được cho không hoặc bán kèm theo máy (HW)
– Yêu cầu người dùng (1b)
• Dần dần, giá thành SW ngày càng cao và nay cao hơn HW
– Thiết kế và lập trình (2b)
Các đặc tính của SW và HW
– Kiểm thử và bảo trì (2b) HW SW
– Chủ đề nâng cao và tổng kết (1b+1b) • Vật “cứng” • Vật “mềm”
• Đánh giá: Thi hết môn + Đồ án môn học • Kim loại • Kỹ thuật sử dụng • Vật chất • Trừu tượng
Tài liệu tham khảo • Hữu hình • Vô hình
• R. Pressman, Software Engineering: A Practioner’s Approach. 5th Ed., McGraw-Hill, 2001
• Sản xuất công nghiệp bởi máy móc là chính
• Sản xuất bởi con người là chính
• 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
• Định lượng là chính • Định tính là chính Việt) • Hỏng hóc, hao mòn • Không hao mòn
• 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)
Đị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
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 Đị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 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 Phần mềm là gì ?
– 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)
Cấu trúc phần mềm
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
Thủ tục (procedure) phần mềm
quản lý phát triển phần mềm
• Là những quan hệ giữa các trình tự mà phần mềm đó có
Nhóm các chương trình
• 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à 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
• 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 xử lý dữ liệu
• Thiết kế cấu trúc trước rồi sang chức năng
• 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 1.3 Các khái niệm
hiệu năng xử lý của phần cứng (ví dụ như OS là chương trình hệ thống)
• Khi chế tác phần mềm cần nhiều kỹ thuật
• 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
– 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ỉ
gói, phần mềm của người dùng, . . . tiêu định tính Nhóm các tư liệu
– 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
• 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
tiếp cận khoa học mang tính định lượng
• Để 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
• Từ phương pháp luận triển khai đến kỹ thuậ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
Các khái niệm (Software concepts)
Những yếu tố khác
• Khái niệm tính môđun (modularity concept)
• 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
• Khái niệm chi tiết hóa dần từng bước (stepwise refinement concept)
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 ở
• Khái niệm trừu tượng hóa (abstraction concept): về thủ tục, điều khiển, dữ liệu từng người
• Khái niệm che giấu thông tin (information hiding concept)
• 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ả
• Khái niệm hướng đối tượng (object oriented)
1.2 Kiến trúc phần mềm
Từ phương pháp luận phần mềm sang kỹ thuật 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)
Kiến trúc phần mềm
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)
Chuẩn phân chia môđun
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 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
1.3.2 Chi tiết hóa từng bước ENDIF
Cách tiếp cận từ trên xuống (top-down approach) ENDIF ENDDO KếtThúc
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
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
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
– 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 đó
• 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
– Trừu tượng dữ liệu: tập hợp dữ liệu mô tả đối tượng dữ liệu nào đó ra vị trí của nó
– 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
• 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 đó trong
• Chọn giải thuật tìm kiếm nhị phân (pp nhị phân)
• Ví dụ: Mở cửa. Thủ tục: Mở gồm . . .; Dữ liệu: Cửa là . . .
Cụ thể hóa thủ tục qua các chức năng
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
• 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ể hóa bước tiếp theo
• Có thể sao chép rất đơn giản
1.5 Thế nào là phần mềm tốt ?
Mức mô tả chương trình (bằng PDL) 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
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
1.5.1 Các chỉ tiêu cơ bản bách
• Phản ánh đúng yêu cầu người dùng (tính hiệu quả - effectiveness)
• Khủng hoảng là gì ? [Webster’s Dict.]
• Chứa ít lỗi tiềm tàng
– Đ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
• Giá thành không vượt quá giá ước lượng ban đầu chủ chốt
• Dễ vận hành, sử dụng
– Đ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
• Tính an toàn và độ tin cậy cao
• Trong phần mềm: Day dứt kinh niên (chronic affliation, by Prof. Tiechrow, Geneva, Arp. 1989)
1.5.2 Hiệu suất xử lý cao
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
• Hiệu suất thời gian tốt (efficiency):
phát triển phần mềm máy tính, như
– Độ phức tạp tính toán thấp (Time complexity)
• 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 ?
– Thời gian quay vòng ngắn (Turn Around Time: TAT)
• Phải xử lý ra sao khi bảo dưỡng phần mềm đã có ?
– Thời gian hồi đáp nhanh (Response time)
• Phải giải quyết thế nào khi thiếu kỹ thuật viên phần mềm?
• Sử dụng tài nguyên hữu hiệu: CPU, RAM, HDD, Internet resources, . . .
• 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 ?
1.5.3 Tính dễ hiểu
• Phải xử lý ra sao khi sự cố phần mềm gây ra những vấn đề xã hội ?
• Kiến trúc và cấu trúc thiết kế dễ hiểu Một số yếu tố
• Dễ kiểm tra, kiểm thử, kiểm chứng
• 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 • Dễ bảo trì
• Đổi vai trò giá thành SW vs. HW
• 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
• Công sức cho bảo trì càng tăng thì chi phí cho Backlog càng lớn
Tính dễ hiểu: chỉ tiêu ngày càng quan trọng
• 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
1.6 Các ứng dụng phần mềm
So sánh chi phí cho Phần cứng và 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)
So sánh chi phí cho các pha
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 đó
(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ẽ Chương 3
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)
Công nghệ học Phần mềm
(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 (Software Engineering)
giảm chất lượng phần mềm
(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
3.1 Lịch sử tiến triển Công nghệ học phần mềm
hiện ra lỗi, thì thường bàn giao sản phẩm không đúng hạn
3.2 Sự tiến triển của các phương pháp thiết kế phần mềm
(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
3.3 Định nghĩa Công nghệ học 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
3.4 Vòng đời của phần mềm
(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
3.5 Quy trình phát triển phần mềm
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
3.1 Lịch sử tiến triển của CNHPM
(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
• 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
hệ thống đúng đắn hay không cứng
(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
• 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
(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
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
(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
• 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
(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 Đ
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
â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 để
• 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ề
tạo ra phần mềm tốt!
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
• 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)
• 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
• 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)
• 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 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
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
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
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.
(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 Warnier (1974)
năng suất) và độ tin cậy của phần mềm, đồng thời giảm chi phí giá thành
• Trừu tượng hóa dữ liệu: B.H. Liskov (1974);D.L. Parnas (1972)
3.4 Vòng đời phần mềm (Software life-cycle)
Phát triển: nửa đầu 1980
• 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
• 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
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) năm 1970
• 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ế
• Bộ khởi tạo chương trình (program generators: pre-compiler; graphics-input editors, etc.)
tạo, kiểm thử, bảo trì. Biểu diễn các pha có khác nhau theo từng người
• Ngôn ngữ đối thoại đơn giản (4GL, DB SQL)
Mô hình vòng đời phần mềm của Boehm
• 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
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
Hình thái sản xuất Phần mềm
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
Suy nghĩ mới về vòng đời phần mềm
• 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
(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
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ư
so với lập trình, kiểm thử và chuyển giao phần mềm
• IEEE [1993]: CNHPM là
(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,
(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 cũng như chi tiết hóa
hành và bảo trì phần mềm;
(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)
(2) nghiên cứu các phương pháp tiếp cận được dùng trong (1)
(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
• 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
(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
phần mềm máy tính
(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
• 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
chất lượng của từng quy trình và của chính phần mềm
phát triển 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
• 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
(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,
(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
sửa chữa, nâng cấp phần mềm
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
Các phương pháp luận và kỹ thuật cho từng pha
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 Tên pha Nội dung nghiệp vụ Phương pháp, kỹ thuật
Engineering is a scientìic field to deal with methodologies, techniques and tools integrated in software Xác định
Đặc tả yêu cầu người dùng
production-maintenance process to obtain software with desired qualities] Phân tích cấu trúc hóa yêu cầu
Xác định yêu cầu phần mềm
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ở Thiết kế
Thiết kế cơ bản phần mềm
(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 Thiết kế cấu trúc hóa hệ thống
Thiết kế cấu trúc ngoài của phần mềm
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 Lập trình cấu trúc Thiết kế
Là thiết kế chi tiết: Thiết kế cấu trúc bên trong của phần
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 Phương pháp Jackson chương trình
mềm (đơn vị chương trình hoặc môđun)
(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 Phương pháp Warnier
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 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ảo
Phương pháp kiểm thử chương
• Công nghệ học Hệ thống / Thông tin và mô hình hóa (System / Information engineering and
Kiểm tra chất lượng phần mềm đã phát triển chất lượng trình
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 Vận hành
Sử dụng, vận hành phần mềm đã phát triển. Biến đổi, điều Chưa cụ thể
• 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à Bảo trì chỉnh phần mềm
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
3.5 Quy trình phát triển phần mềm
• 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
• 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
Đ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!
3.5.3 Mô hình chế thử (Prototyping model)
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
• 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
Mô hình chế thử: Khi nào ?
from the process and from testing innovative ideas and technologies
• 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õ
18 key process areas (KPAs) for CMM 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
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)
Mô hình phát triển ứng dụng nhanh
3.5.2 Mô hình tuyến tính
Đ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 được dùng nhất Mô hình tuyến tính
Mô hình xoắn ốc (spiral) 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 ?
RAD: Data and Process modeling
• 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
• 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
• 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
từng đối tượng và xác lập quan hệ giữa các đối tượng
• 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ý
• 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
• Kỹ nghệ: Xây dựng một hay một số biểu diễn của ứng dụ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
• 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
RAD: Appl. Generation and Testing luyện, . . .)
• 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
• Đá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
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
đoạn kỹ nghệ và cài đặt
• 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ũ
Mô hình xoắn ốc: Mạnh và yếu?
đã được kiểm thử và dùng lại)
• Tốt cho các hệ phần mềm quy mô lớn RAD: Hạn chế ?
• Dễ kiểm soát các mạo hiểm ở từng mức tiến hóa
• 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
• 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
• 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
• Chưa được dùng rộng rãi như các mô hình tuyến tính hoặc chế thử
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
Mô hình xoắn ốc WINWIN năng cao
• 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)
• Mạo hiểm kỹ thuật cao thì không nên dùng RAD
– Khách thì có phần mềm thỏa mãn yêu cầu chính
3.5.5 Các mô hình tiến hóa: gia tăng, xoắn ốc, xoắn WINWIN, ...
– Người phát triển thì có kinh phí thỏa đáng và thời gian hợp lý
• 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
• Các hoạt động chính trong xác định hệ thống:
thêm, hoàn thiện thêm chức năng, tính năng
– Xác định cổ đông (stakeholders)
• 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
– Xác định điều kiện thắng của cổ đông
(versions) ngày càng hoàn thiện hơn, phức tạp hơn
– Thỏa hiệp điều kiện thắng của các bên liên quan
• Các mô hình: incremental, spiral, WINWIN spiral, concurrent development model
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 Mô hình gia tăng
• 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 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
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
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
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
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, . . .)
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
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ả đó Phần II
Phương pháp Quản lý Dự án CNTT Chương 4
Quản lý dự án CNTT • 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 Để • tránh thất bại
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
Phương pháp Quản lý Dự án CNTT I. Tổng quan
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ó
Thực hiện dự án không có nghĩa là Quản trị dự án!
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ý
Đị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%
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
Những nguyên nhân thất bại
Cấu trúc Phương pháp QLDA 10 quy tắc vàng
• Quản lý dự án thành công chính là vấn đề về con người
o nhưng không được quên quản trị •
Khám phá các nguồn hỗ trợ và chống đỡ •
Xây dựng & Thông qua kế hoạch quản lý
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
Những rủi ro gặp phải khi không
Các lợi ích khi lập kế hoạch quản lý
o hãy đặt mình vào địa vị của họ
lập kế hoạch quản lý
• Thiết lập kế hoạch của bạn sao cho có thể chỉnh sửa dễ dàng • Khởi đầu sai lệch
• Đáp ứng được các mục tiêu của nhà tài trợ
• Đối mặt với từng sự kiện như là nó đã có từ trước • Bị nhầm lẫn
• Gây dựng lòng tin của nhà tài trợ
• Sử dụng quản trị để hỗ trợ cho các mục đích của dự án
• Không đáp ứng được sự mong đợi của
• Thiết lập hướng làm việc chung
• 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
nhà tài trợ và/hoặc của mục tiêu
• Bao quát được các thách thức
• Đọc lại phạm vi và các mục tiêu của dự án mỗi tuần 1 lần • Thông tin nghèo nàn
• Mở ra các kênh thông tin lien lạc • Không ngạc nhiên!
• Bắt đầu dự án với một phương thức có hệ thống
II. Lập kế hoạch quản lý •
Giá trị của các mục tiêu rõ ràng
Xác định ranh giới của dự án
• Thiết lập sự mong đợi của nhà tài trợ dự án và các nhà đầu tư
o đội lập kế hoạch, văn bản/thông tin hiện có • •
Đưa ra điểm mục tiêu để hướng dẫn đội dự án
Xây dựng các lựa chọn tiếp cận dự án
• Cho phép bạn xác định thời điểm dự án kết thúc!
o chiến lược thực hiện và các phương pháp luận tổ chức dự án •
Các bước xác định phạm vi dự án
Xây dựng các ước tính ban đầu • •
Xem xét lại các văn bản hiện có
Xây dựng cơ sở hạ tầng nguồn
• Lập danh sách các văn bản/ thông tin chưa đầy đủ hay còn thiếu o môi trường làm việc •
• 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
Xây dựng cơ sở hạ tầng của dự án
• 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
o 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ế
• Tiếp tục kết hợp chặt chẽ các chi tiết vào kế hoạch quản lý hoạch • • Đạ t được thoả thuận
Lập thành văn bản về kế hoạch quản lý
Ích lợi của việc xác định phạm vi
Các vai trò và trách nhiệm của dự án
• “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
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
• 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
• Sử dụng các động từ hành động
• Danh sách các thành viên tiềm năng trong ban điều hành dự án Tổ chức dự án
• Biểu đồ tổ chức dự án:
o cấu trúc quản lý dự án o 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
Quy trình tổ chức dự án
Đảm bảo quy trình kiểm soát dự án...
• 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
Quy trình báo cáo và kiểm soát dự án
• 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
Ví dụ về cấu trúc Quản lý dự án
• Lựa chọn phần mềm quản lý dự án Sổ tay quản trị • Các chính sách
• Các thủ tục hành chính • Các tiêu chuẩn
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
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;
Cơ cấu tổ chức 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à,
Những điểm chính:
• 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ả.
• 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
Kế hoạch quản lý là nền tảng cho việc quản lý một dự án
o giám đốc dự án điều hành nhóm quản lý
• Điểm chủ yếu để hiểu một dự án là
o các mối quan hệ cần phải được thiết lập
o 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
• 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ị
• Nền tảng vững chắc cho quản lý dự án
o không cần thiết phải có cán bộ làm việc full time o Truyền thông
o không thể được thực hiện bởi quản trị viên/giám đốc dự án
Vai trò và trách nhiệm của dự án
III. Tổ chức dự án Vai trò Trách nhiệm
Các kết quả chuyển giao từ tổ chức 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
• Xác định “những người có ảnh hưởng” của dự án Giám đốc dự án
Đại diện cho nhà tài trợ dự án
• Xác định những lĩnh vực chủ yếu có lực cả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
• Rủi ro không thể được loại trừ triệt để dự án)
Định nghĩa quản lý rủi ro 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
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 Các thành viên nhóm Hoàn thành nhiệm vụ
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
Giá trị của quản lý rủi ro
Các yêu cầu về mô tả
• Giảm thiểu ảnh hưởng của các sự cố không biết trước cho dự án
• Ngắn gọn và súc tích
• Nâng cao xác suất thực hiện thành công dự án • Xác định rõ:
• Tạo ra ý thức kiểm soát
o Các mục đích và mục tiêu cơ bản
• Có được các giải pháp hiệu quả và kịp thời
o Những trách nhiệm cơ bản
Khi nào cần quản lý rủi ro o Số thành viên
• Lập kế hoạch quản lý o Họp thường kỳ
• Khi trách nhiệm đối với dự án sẵn sàng thực thi
Văn phòng dự án là gì?
• Khi khôi phục một dự án đã bỏ dở Là trung tâm của:
• Trong suốt quá trình rà xét dự án • Họp
• Khi có sự sai lệch lớn so với kế hoạch xảy ra
• Điều phối, kết hợp
Quy trình quản lý rủi ro • 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
Nhiệm vụ và trách nhiệm của văn phòng dự án
Hoạt động ngăn ngừa (ví dụ)
Độ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:
• Đư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
Tổ chức dự án - Các điểm chính
• 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)
Các nhân tố thành công đối với một cơ cấu tổ chức dự án mạnh: •
Hành động dự phòng
Nhà tài trợ có trách nhiệm cao đối với tổ chức • Phải:
Hỗ trợ tích cực từ ban điều hành • •
Dựa trên những thừa nhận từ thực tiễn (ví dụ: các nguồn sẵn có)
Phân định rõ trách nhiệm, thẩm quyền, trách nhiệm giải trình • •
Các thành viên trong nhóm phải hiểu được (và uỷ ban điều hành)
Trao đổi hợp lý giữa cán bộ kỹ thuật và cán bộ chức năng • •
Phải được kiểm tra khi tính khả thi bị nghi ngờ
Hoàn thành công việc dự án với nguồn lực ít nhất •
Chương trình quản lý rủi ro hiệu quả
Dòng thông tin liên lạc hiệu quả • •
Tập trung vào việc phòng ngừa hơn là chữa trị
Tỉ lệ cán bộ so với người quản lý nhỏ
• Bao gồm đánh giá rủi ro theo thời kỳ trong suốt vòng đời của dự án
• 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
• 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!
IV. Quản lý rủi ro Đị
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ý. nh nghĩa rủi ro Rủi ro là: •
V. Phát triển nhóm
Những sự kiện có thể làm phá vỡ một dự án •
Xây dựng nhóm - Các mục tiêu
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
• 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ả
đúng kế hoạch đã định • •
Xác định các phương pháp để xây dựng nhóm có hiệu quả
Có thể quản lý được Nhóm hiệu quả
Các lý do cần có quản lý rủi ro • •
Các mục đích được thống nhất
Tất cả các dự án đều phụ thuộc vào rủi ro • •
Nhóm tin tưởng vào vai trò và mục tiêu
Tiến trình sẽ không đúng theo kế hoạch trong một số giai đoạn của dự án
• 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 nhân tố quản lý chất lượng hiệu quả:
• Các ý tưởng được trao đổi và triển khai • Cam kết quản lý
• Đưa ra các giải pháp hiệu quả
• Người sử dụng tham gia
• Mối quan hệ hợp tác và hỗ trợ giữa các thành viên của nhóm
• Cấu trúc của phương pháp tiếp cận
Quy trình xây dựng nhóm
• 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ý
VII. Lập kế hoạch làm việc chi tiết
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:
o thường không nhỏ hơn 7 người/giờ làm việc
Nhóm làm việc thành công được xây dựng trên cơ sở: •
o thường không nhiều hơn 70 người/giờ làm việc Mục tiêu rõ ràng •
o thường không sử dụng nhiều hơn 2 nguồn Trách nhiệm rõ ràng •
o thường xuyên có một văn bản nhiệm vụ xác định
Thông tin liên lạc hiệu quả
Cấu trúc phân chia công việc (WBS)
• 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
VI. Quản lý chất lượng
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
Cân bằng chất lượng
Lập kế hoạch - Xây dựng WBS
Các khái niệm chất lượng chủ chốt •
Đạt được về chất lượng phải được lên kế hoạch - không tuỳ tiện
Nhiệm vụ phải được xác định là:
• Đạ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
• đượ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)
• Đạt được chất lượng phụ thuộc vào sự hỗ trợ quản lý
• trách nhiệm của một cá nhân
Quản lý chất lượng • có hạn
o 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
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
Lập báo cáo và kiểm soát dự án - các mục tiêu
• Chuyển các thông tin phụ thuộc vào thành một công cụ lập kế hoạch Để có thể :
Chỉ định nguồn lực cho các nhiệm vụ
• 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
Các nguyên tắc cơ bản
• Để 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
• Sử dụng hợp lý nguồn dự án
• Kinh nghiệm & kỹ năng đáp ứng nhu cầu nhiệm vụ
• Đá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
• không bỏ qua những cán bộ thiếu kinh nghiệm
• Đánh giá tầm quan trọng cuả một chu kỳ kiểm soát dự án được xác định.
• Sự sẵn sàng không phải là một kỹ năng Các định nghĩa
Nguồn lực của dự án là những gì? Kiểm soát dự án:
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ổ
• Nắm bắt và quản lý tiến trình
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.
Lập báo cáo dự án:
Các loại nguồn tiêu biểu bao gồm:
• Truyền bá hiệu quả những kiến thức này
• 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
Lập báo cáo và kiểm soát dự án là nền tảng để quản lý dự án
sàng để hoàn thành mục tiêu.
• Quản trị viên dự án có thể:
• 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
o Báo cáo khách quan về thực trạng dự án
công cụ kiểm tra đặc biệt.
o Xác định những cản trở và hành động hiệu chỉnh
• 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
o Triển khai các giải pháp
chì đến đĩa mềm và các đồ vật khác.
o Hiểu sự ảnh hưởng của công việc tương lai
• 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
o Đưa ra những quyết định hợp lý dựa trên thông tin xác thực thu nhập của dự án.
• Quản trị viên dự án, trưởng nhóm và thành viên nhóm phải:
Lên lịch trình nên...
o Lắng nghe tin nhắn chuyển đến
• Giảm tối đa thời gian bỏ phí
o Chấp nhận tin xấu và tốt
• Tận dụng tối đa các nguồn
o Hỗ trợ tích cực các thành viên trong nhóm để vượt qua trở ngại
• Dàn xếp chỗ thừa và chỗ thiếu của các nguồn
Trao đổi tình trạng dự án •
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ẽ:
Xem xét các hạn chế của: •
o các nhiệm vụ phụ thuộc
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 • o các nguồn sẵn có
Đưa ra thông tin chính xác tin cậy dựa trên kế hoạch dự án
• Là một quy trình lặp lại
• Nêu bật những điểm ngoại lệ so với kế hoạch
o thời gian biểu của quy trình
• Cung cấp thông tin kịp thời o rà xét thời gian biểu
• Bao gồm cả mức nỗ lực có thể chấp nhận o sửa thời gian biểu
Lập báo cáo - the WBS
o 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
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ế
Lập kế hoạch, theo dõi, báo cáo
Các nhân tố thành công
• 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
VIII. Kiểm soát và lập báo cáo dự án
Các nhân tố thành công
Lập báo cáo và kiểm soát dự án
• 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 o không thoả mãn o không hoảng sợ
Lập báo cáo & kiểm soát dự án
Những điểm chính:
• 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
IX. Quản lý vấn đề và kiểm soát thay đổi
Quản lý sự thay đổi và vấn đề Các mục tiêu
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ự
Khuôn khổ kiểm soát dự án kiện Về nguyên tắc
Các phương tiện quản lý sự kiện và thay đổi hiệu quả:
• 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
o 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
o bao gồm tất cả các khoản mục hiện tại và đã hoàn thiện
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
Chu kỳ kiểm soát dự án
Một chu kỳ kiểm soát dự án thống nhất:
• 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
Chu kỳ kiểm soát dự án - các yếu tố
• 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
Các kỹ thuật và quy trình ... 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
Kiểm soát phiên bản
Giải pháp quản lý vấn đề và thay đổi
Định nghĩa thay đổi:
bất cứ hoạt động nào thay đổi: • phạm vi
Các chức năng quản lý cấu hình • 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
Kiểm soát thay đổi và giải pháp cho vấn đề
Các nhân tố thành công
• 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 đề Chi phí thay đổi
Một quy trình quản lý cấu hình hiệu quả phải có các đặc tính sau:
• 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
Quản lý thay đổi và vấn đề
Các điểm chính đã học
XI. Hoàn tất dự á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 Hoàn thiện 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
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
• 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
đượ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. Nguyên tắc
X. Quản lý cấu hình
• 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
Đa số nghĩ rằng... Quản lý cấu hình
giai đoạn khác của dự án
• Đây là vấn đề về LANs, WANs, phần cứng, ...
• 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
• Đây là các hoạt động mang tính kỹ thuật cao
• 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
• Nó liên quan rất ít đến quản lý dự án
Quy trình hoàn thiện dự án
Quản lý cấu hình ...thực hiện hai chức năng chính
• 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 Phần III
• Tiến hành rà xét các hoạt động •
Yêu cầu người dù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 User’s Requirements
• 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
Chương 5: Phương pháp xác định yêu cầu
• Giải thể tổ chức dự án 5.1.
Kỹ thuật xác định yêu cầu
• Tiến hành các cuộc họp kết thúc dự án 5.2.
Nội dung xác định yêu cầu
• Tiến hành rà xét sau thực hiện 5.3.
Các nguyên lý phân tích yêu cầu
• Thiết lập lại việc phân bổ nhân sự
Tiến hành các cuộc họp kết thúc dự án
5.1. Kỹ thuật xác định yêu cầu phần mềm - SW Requirements Engineering Lịch trình
• 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
Xem xét các yêu cầu dự án
Thực trạng cuối cùng
diện, các yêu cầu đặc biệt khác • các mục tiêu dự án
• kế hoạch so với thực tế
• 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: • phạm vi dự án
• phân tích sự khác nhau và thảo luận
– Các yêu cầu về phần mềm (Software)
• các kết quả bàn giao chính
Xem xét các khoản mục mở
– Các yêu cầu về phần cứng (Hardware)
• phương pháp tiếp cận dự án • danh mục nổi bật
– Các yêu cầu về dữ liệu (Data)
• lịch trình ở mức cao
• danh mục các vấn đề thay đổi
– Các yêu cầu về con người (People, Users)
Xem xét các thành quả dự án
Khái quát các bước tiếp theo
• 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à • nền tảng
• hoàn tất lịch trình chuyển đổi
mong muốn của khách hàng - người sử dụng phần mềm • kết quả bàn giao
• các mục tiêu/ kế hoạch đối với rà xét sau
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 đặc tính nổi bật thực hiện •
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 lợi ích lớn đã đạt được
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
Tiến hành rà xét sau thực hiện •
mô tả một cách hợp lý
Quy trình và việc hoàn tất dự án
5.2. Nội dung xác định yêu cầu phần mềm - Contents of Requirements Engineering
o tiến hành tại thời điểm kết thúc dự án
• Phát hiện các yêu cầu phần mềm (Requirements elicitation)
§ thực hiện và theo dõi trong khuôn khổ dự án
• 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)
Lợi ích kinh doanh/ tính hiệu quả của dự án
• Mô tả các yêu cầu phần mềm (Requirements specification)
o Tiến hành vài tháng sau khi triển khai
• Mô hình hóa hệ thống (System modeling)
§ Thực hiện và theo dõi ngoài dự án
• Kiểm tra tính hợp lý các yêu cầu phần mềm (Requirements validation)
§ 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
• Quản trị các yêu cầu phần mềm (Requirements management) các thành viên
Quy trình xác định yêu cầu phần mềm
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
o 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
o nó cũng phải được triển khai!
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 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 The Analysis Model 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
• 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
• Đặ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)
5.2.1. Phát hiện yêu cầu phần mềm - (Requirements Elicitation)
• Đặc tả mô tả (Descriptive Specifications)
Các vấn đề của phát hiện yêu cầu phần mềm (Problems)
– Biểu đồ thực thể liên kết (Entity-Relationship Diagrams)
• Phạm vi của phần mềm (Scope)
– Đặc tả Logic (Logic Specifications)
• Hiểu rõ phần mềm (Understanding)
– Đặc tả đại số (Algebraic Specifications)
• Các thay đổi của hệ thống (Volatility)
Biểu đồ luồng dữ liệu (DFD)
Phương pháp phát hiện yêu cầu phần mềm - Requirements Elicitation Methodology
• 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)
• 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
• Các ký pháp sử dụng:
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ể hiện các chức năng (functions)
thống giúp chúng ta xác định yêu cầu phần mềm
Thể hiện luồng dữ liệu
• 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” Kho dữ liệu
• 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
Vào ra dữ liệu và tương tác giữa hệ thống và người sử dụng
• Thiết kế các kịch bản sử dụng của phần mềm
Sản phẩm (output) của “phát hiện yêu cầu phần mềm”
Ví dụ mô tả biểu thức toán học bằng DFD
• 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
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
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
• 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
Ví dụ đặc tả các chức năng của thư viện qua DFD
• 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
• Đá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
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
Requirements Specification
Các hạn chế của DFD Người mượn
• Ý 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
• 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
Ví dụ của chức năng tìm kiếm:
sách các chủ đề liên quan của các quyển sách
If NSD nhập vào cả tên tác giả và tiêu đề sách Then
• 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ó
tìm kiếm sách tương ứng, không có thì thông báo lỗi
thể có 1 trong 5 trạng thái sau:
Elseif chỉ nhập tên tác giả Then
• (AV) - Available được phép mượn, (CO) - (BR) - đã mượn (Check Out; Borrow), (L): Last, (R):
hiển thị danh sách các sách tương ứng với Remove
tên tác giả đã nhập và yêu cầu NSD lựa chọn sách
• FSM đặc tả các trạng thái
Elseif chỉ nhập tiêu đề sách Then . . . Endif
• 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ực hiện 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ả, . . . chức năng D.
Mô hình đặc tả :
– Chức năng D có thể cần cả A, B và C
Mô hình thực thể liên kết
– Chức năng D có thể chỉ cần một trong A, B và C để thực hiện
• 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ệ
– Chức năng D có thể kết xuất kết quả cho một trong E và F thống dữ liệu lớn
– Chức năng D có thể kết xuất kết quả chung cho cả E và F ER Model
– Chức năng D có thể kết xuất kết quả riêng cho cả E và F – Thực thể – Quan hệ – Thuộc tính
• DFD không xác định sự đồng bộ giữa các chức năng / mô-đun Biểu đồ thực thể
– A xử lý dữ liệu và B được hưởng (nhận) các kết quả được xử lý từ A
• 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
– A và B là các chức năng không đồng bộ (asynchronous activities) vì thế cần có buffer để ngăn
Thực thể có thể có mối quan hệ: – person owns car
chặn tình trang mất dữ liệu
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
• Thực thể có các thuộc tính
• Các chức năng chuyển tiếp
• 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
δ :Q×I →Q
– đặ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
Đặ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:
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
– Mượn sách / Trả sách
Quan hệ – chỉ ra mối liên quan giữa các đối tượng dữ liệu
– 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
Ø Cardinality : chỉ ra định lượng của mối quan hệ
– Tìm kiếm sách quá hạn trả, . . .
1:1 one-to-one 1:N one-to-many M:N many-to-many
• Các yêu cầu đặc biệt của thư viện:
Ø Modality : 0 – có thể có, có thể không có quan hệ
– Độ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
1 – bắt buộc có quan hệ
– 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 đó, . . . Các đối tượng – Tên sách Mã quyển Nhân viên phục vụ
Ví dụ ERD mô tả thư viện
