Giáo trình Nhập môn công nghệ học phần mềm

Phần I

Nhập môn

Công nghệ học Phần mềm

(Introduction to Software Engineering)

Giới thiệu chung về CNHPM

Chương 1: Bản chất phần mềm

1.1

1.2

1.3

1.4

1.5

Định nghĩa chung về phần mềm

Kiến trúc phần mềm

Các khái niệm

Đặc tính chung của phần mềm

Thế nào là phần mềm tốt ?

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,...

Nội dung: gồm 6 phần với 11 chương

1.6 Các ứng dụng phần mềm

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

–

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)

•

Các đặc tính của SW và HW

HW

SW

Chủ đề nâng cao và tổng kết (1b+1b)

Đánh giá: Thi hết môn + Đồ án môn học

•

Vật “cứng”

Kim loại

Vật chất

Hữu hình

•

Vật “mềm”

Kỹ thuật sử dụng

Trừu tượng

•

Tài liệu tham khảo

Vô hình

•

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)

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

Sản xuất bởi con người là chính

Định tính là chính

Không hao mòn

•

Đị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

quản lý phát triển phần mềm

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ó

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à 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

•

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, . . .

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

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

•

Từ phương pháp luận triển khai đến kỹ thuật

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

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

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)

•

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ả

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

Từ phương pháp luận phần mềm sang kỹ thuật phần mềm

•

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

ENDIF

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)

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 đó

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

•

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)

trong

•

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ể sao chép rất đơn giản

Cụ thể hóa bước tiếp theo

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

bách

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

•

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

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

phát triển phần mềm máy tính, như

•

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)

•

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 ?

•

Sử dụng tài nguyên hữu hiệu: CPU, RAM, HDD, Internet resources, . . .

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

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

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ẽ

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

Chương 3

Công nghệ học Phần mềm

(Software Engineering)

(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

(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

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

(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

(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

(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!

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

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

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.

Warnier (1974)

Trừu tượng hóa dữ liệu: B.H. Liskov (1974);D.L. Parnas (1972)

(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

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

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

Mô hình vòng đời phần mềm của Boehm

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

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ư

•

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)

(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

(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

•

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

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

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

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]

Tên pha

Nội dung nghiệp vụ

Phương pháp, kỹ thuật

Phân tích cấu trúc hóa

Xác định

yêu cầu

Đặc tả yêu cầu người dùng

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ở

(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

Thiết kế

hệ thống

Thiết kế cơ bản phần mềm

Thiết kế cấu trúc ngoài của phần mềm

Thiết kế cấu trúc hóa

(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

(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)

Lập trình cấu trúc

Phương pháp Jackson

Phương pháp Warnier

Thiết kế

Là thiết kế chi tiết: Thiết kế cấu trúc bên trong của phần

chương trình mềm (đơn vị chương trình hoặc môđun)

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

(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

•

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

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

Đảm bảo

chất lượng

Phương pháp kiểm thử chương

trình

Kiểm tra chất lượng phần mềm đã phát triển

Vận hành

Bảo trì

Sử dụng, vận hành phần mềm đã phát triển. Biến đổi, điều

chỉnh phần mềm

•

Chưa cụ thể

3.5 Quy trình phát triển 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

from the process and from testing innovative ideas and technologies

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

18 key process areas (KPAs) for CMM

•

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 ?

•

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

RAD: Data and Process modeling

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

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, . . .)

•

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

•

RAD: Appl. Generation and Testing

•

Đá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

•

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)

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ử

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ỡ

Mô hình xoắn ốc WINWIN

•

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

•

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ý

3.5.5 Các mô hình tiến hóa: gia tăng, xoắn ốc, xoắn WINWIN, ...

•

Các hoạt động chính trong xác định hệ thống:

•

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

–

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

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

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

Để tránh thất bại

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

Thực hiện dự án không có nghĩa là Quản trị dự án!

là duy nhất, hoặc về sản phẩm hoặc về môi trường của 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

Cấu trúc Phương pháp QLDA

Những nguyên nhân thất bại

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ị

o

·

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

Xây dựng & Thông qua kế hoạch quản lý

Những rủi ro gặp phải khi không

lập kế hoạch quản lý

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ọ

·

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!

·

Khởi đầu sai lệch

Bị nhầm lẫn

Không đáp ứng được sự mong đợi của

nhà tài trợ và/hoặc của mục tiêu

Thông tin nghèo nàn

·

Đáp ứng được các mục tiêu của nhà tài trợ

Gây dựng lòng tin của nhà tài trợ

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 lien lạc

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

độ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

·

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!

o

·

o

Các bước xác định phạm vi dự án

·

Xây dựng các ước tính ban đầu

Xây dựng cơ sở hạ tầng nguồ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

o

môi trường làm việc

·

Xây dựng cơ sở hạ tầng của dự án

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ế

hoạch

·

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

Sử dụng các động từ hành động

·

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:

Tổ chức dự án

o

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

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

Lựa chọn phần mềm quản lý dự án

Ví dụ về cấu trúc 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;

Xác định nguồn nhân lực cần thiết để thực hiện công việc dự án; và,

Cơ cấu tổ chức dự án

Những điểm chính:

·

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

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ả.

o

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

Kế hoạch quản lý là nền tảng cho việc quản lý một dự án

·

Đ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

·

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ị

o

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

o

Vai trò và trách nhiệm của dự án

Vai trò

Trách nhiệm

III. Tổ chức dự án

Các kết quả chuyển giao từ tổ chức dự án

Nhà tài trợ dự án

Giám đốc dự án

Ban chỉ đạo

“Người đứng đầu”, chủ sở hữu và nhà tài chính của dự án

Đại diện cho nhà tài trợ dự án

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

Thừa nhận các kết quả bàn giao chủ yếu về nghiệp vụ

·

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

Nhóm nghiệp vụ

Quản lý dự án

Nhóm trưởng

Đ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)

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

·

Rủi ro không thể được loại trừ triệt để

Đị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

Giá trị của quản lý rủi ro

Các thành viên nhóm Hoàn thành nhiệm vụ

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

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

·

Ngắn gọn và súc tích

Xác định rõ:

o

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

Có được các giải pháp hiệu quả và kịp thời

Khi nào cần quản lý rủi ro

·

Lập kế hoạch quản lý

Họp thường kỳ

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

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

Quy trình quản lý rủi ro

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

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)

Tổ chức dự án - Các điểm chính

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

Phải:

·

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ả

·

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ờ

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ị

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

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ý.

IV. Quản lý rủi ro

Định nghĩa rủi ro

Rủi ro là:

V. Phát triển nhóm

Xây dựng nhóm - Các mục tiêu

·

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

·

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ả

đúng kế hoạch đã định

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

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.

·

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

Các nhân tố quản lý chất lượng hiệu quả:

·

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ả

·

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

Mối quan hệ hợp tác và hỗ trợ giữa các thành viên của nhóm

Quy trình xây dựng nhóm

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

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

Nhóm làm việc thành công được xây dựng trên cơ sở:

·

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

Cấu trúc phân chia công việc (WBS)

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

Lập kế hoạch - Xây dựng WBS

Cân bằng chất lượng

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

Đạ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ý

Nhiệm vụ phải được xác định là:

·

đượ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

Quản lý chất lượng

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

Lập báo cáo và kiểm soát dự án - các mục tiêu

Để có thể :

·

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

·

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.

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

Các định nghĩa

Kiểm soát dự án:

Nguồn lực của dự án là những gì?

·

Nắm bắt và quản lý tiến trình

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:

Lập báo cáo dự án:

·

Truyền bá hiệu quả những kiến thức này

Lập báo cáo và kiểm soát dự án là nền tảng để quản lý dự án

·

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.

·

Quản trị viên dự án có thể:

o

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:

o

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ê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:

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ẽ:

·

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

o

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

o

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

Lập báo cáo - the WBS

·

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

3

4

5

Xác định phạm vi và mục tiêu của từng nhiệm vụ

Xác định những nguồn nào cần để thực hiện từng nhiệm vụ

Xác định thời gian cần sử dụng nguồn của từng nhiệm vụ

Xác định thời điểm bắt đầu và kết thúc của từng nhiệm vụ

Bao gồm các ước tính thực tế

6

7

8

Giảm tối đa sự thất thường của công việc khi sử dụng từng nguồn

Kết hợp chi phí của các nhiệm vụ và dự phòng

9

10

Tiêu chuẩn hoá dự án để có thể giám sát được

Đư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

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ự

kiện

Khuôn khổ kiểm soát dự á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

Hoàn thiện 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

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

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.

Nguyên tắc

X. Quản lý cấu hình

Đa số nghĩ rằng... 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

giai đoạn khác của dự án

·

Đâ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

·

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

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

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

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.

5.2.

5.3.

Kỹ thuật xác định yêu cầu

Nội dung xác định yêu cầu

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

Thực trạng cuối cùng

•

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

Xem xét các yêu cầu dự án

•

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 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

·

kế hoạch so với thực tế

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 yêu cầu về phần cứng (Hardware)

Các yêu cầu về dữ liệu (Data)

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

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

Khái quát các bước tiếp theo

Xem xét các thành quả dự án

·

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

·

nền tảng

Tại sao cần phải đặt ra yêu cầu phần mềm ?

kết quả bàn giao

đặc tính nổi bật

các lợi ích lớn đã đạt được

•

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ý

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

5.2. Nội dung xác định yêu cầu phần mềm - Contents of Requirements Engineering

o

•

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)

·

Lợi ích kinh doanh/ tính hiệu quả của dự án

•

o

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

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)

§ 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

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

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õ!

o

·

Cải tiến quy trình dự án có thể được xác định

nó cũng phải được triển khai!

Các nhân tố thành công

o

·

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ác vấn đề của phát hiện yêu cầu phần mềm (Problems)

Đặ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)

•

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)

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)

Các ký pháp sử dụng:

•

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.

Thể hiện các chức năng (functions)

Thể hiện luồng dữ liệu

Kho dữ liệu

•

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

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

Ví dụ mô tả biểu thức toán học bằng DFD

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

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

Người mượn

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

•

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

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

•

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

•

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

FSM đặc tả các trạng thái

. . .

Endif

•

Trong DFD không xác định rõ các hướng thực hiện (control aspects)

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ả, . . .

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

chức năng D.

Mô hình đặc tả :

Mô hình thực thể liên kết

–

Chức năng D có thể cần cả A, B và C

•

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ể 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

thống dữ liệu lớn

ER Model

–

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

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

•

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

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

•

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

δ :Q´ I ® Q

Đặc tả các yêu cầu phần mềm bằng FSM

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

Quan hệ – chỉ ra mối liên quan giữa các đối tượng dữ liệu

•

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ả, . . .

Ø 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

•

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ệ

1 – bắt buộc 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

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