1 Phát triển hệ thống 1 1 Giới thiệu 2

1.8.2Lập kế hoạch, quản lí và đánh giá chất lượng

• 
  Việc kiểm thử phần mềm chỉ để loại bỏ các khiếm khuyết và để duy trì chất lượng đã được thiết kế. Mặt khác, QFD là một công nghệ để sinh ra phần mềm chất lượng cao hơn. QFD được phát minh ra để làm tăng chất lượng của thiết kế phần cứng. Đại cương về QFD là như sau: với QFD, chất lượng của phần mềm bao gồm các hệ con và các mô đun được biểu diễn như đặc trưng chất lượng cho phép đánh giá rõ ràng và cùng phương pháp đánh giá đó được dùng một cách hệ thống cho chất lượng của các hệ con và các mô đun nữa.
  

• 
  Như chúng ta đều đã biết rõ, máy tính không mềm dẻo. Nói rằng "Máy tính khôn lắm" là không đúng. Đúng hơn phải nói là, "Phần mềm (chương trình) này khôn lắm." Tuy nhiên, chất lượng của phần mềm không bao giờ được cải tiến lên mà không tạo ra phần mềm tốt hơn. Trong máy tính vạn năng, việc đưa dữ liệu kí tự vào thay vì các khoản mục số làm cho máy tính bị kết thúc bất thường. Để tránh điều này, với một chương trình có thể kiểm tra dữ liệu được đưa vào và yêu cầu rằng dữ liệu đó phải được đưa vào lại nếu dữ liệu đầu không phải là số. Nói cách khác, việc đưa ra một chức năng kiểm tra lỗi làm cho chương trình khôn hơn, làm tăng chất lượng phần mềm.
  
• 
  Một chức năng như vậy không nên phụ thuộc vào khả năng của người lập trình. Nó phải được tính tới mà không bị bỏ quên mất trong pha thiết kế nơi các yêu cầu người dùng được cụ thể hoá chi tiết. Nếu sự cần thiết của chức năng kiểm tra được xác nhận như một nhu cầu tiềm tàng của người dùng, nhưng lại không được mô tả trong đặc tả trong pha thiết kế, thì chức năng này sẽ không bao giờ được đạt tới. Những khiếm khuyết bắt nguồn từ các định nghĩa yêu cầu trong pha sớm nhất có thể chỉ được phát hiện ra trong kiểm thử vận hành, pha muộn nhất. Hậu quả là việc sửa chữa rất có thể là điều không thể nào thực hiện được, ngay cả sau khi đã tìm ra khiếm khuyết.
  
• 
  Nói cách khác, nếu được cấp đủ thời gian trong các giai đoạn đầu cho việc kiểm chứng và sửa chữa, thì khối lượng sửa đổi được cần tới trong các pha cuối sẽ được rút bớt lại. Thực tế, người ta nói, "Một giờ được dùng để ngăn cản các khiếm khuyết trong những pha đầu xoá bỏ đi ba tới mười giờ làm việc sửa chữa trong pha cuối." Để làm tăng chất lượng phần mềm, việc thực hiện cái gọi là chu trình Kế hoạch-Thực hiện-Kiểm tra-Hành động Plan-Do-Check-Action (PDCA) -- lập kế hoạch, thực hiện kế hoạch, đánh giá cái ra và chọn hành động dựa trên các đánh giá - là được cần tới.
  

• 
  Có nhiều phương pháp đánh giá phần mềm. Ở đây, chúng ta mô tả sáu đặc trưng chất lượng, được liệt kê trong ISO/IEC 9126 được nêu trong Hình 1-7-1.
  

Hình 1-7-1 Đặc trưng chất lượng của ISO/IEC 9126

• 
  
  
• 
  
  
• 
  
  
• 
  
  
• 
  
  
• 
  
  
• 
  
  
• 
  
  
• 
  
  
• 
  
  
• 
  
  
• 
  
  
• 
  
  
• 
  
  
• 
  
  
• 
  
  
• 
  
  
• 
  
  
• 
  
  
• 
  
  
• 
   Chức năng (đặc trưng chức năng)
  

- Độ chính xác chức năng được cung cấp (tính chính xác)

- Các chức năng đáp ứng cho đặc tả (tính tuân thủ)

- Cung cấp sự dễ dàng nối với các hệ thống khác (tính liên tác)

- Cung cấp tính an ninh bản chất (an ninh)

• 
   Tính tin cậy (đặc trưng tin cậy)
  

Một mức độ hệ thống nào đó được duy trì ngay cả khi xuất hiện trục trặc: dung sai.

Hoạt động bình thường được khôi phục sẵn sàng khi lỗi xuất hiện: tính khôi phục được.

• 
   Tính dùng được (đặc trưng dễ dùng)
  
• 
  - Vận hành dễ dàng: tính hiểu được.
  

- Cho phép quản lí thao tác dễ dàng: tính vận hành.

• 
   Tính hiệu quả (đặc trưng hiệu năng)
  

- Cho phép dùng hiệu quả các tài nguyên hệ thống: hành vi tài nguyên.

• 
   Tính bảo trì được (đặc trưng bảo trì)
  
• 
  - Cho phép phân tích dễ dàng các tài liệu thiết kế và chương trình khi tìm ra lỗi: khả năng phân tích.
  

- Việc sửa đổi hệ thống không ảnh hưởng tới các hệ thống khác: tính ổn định.

- Không đòi hỏi kiểm thử mất công sức sau khi tiến hành sửa đổi: tính kiểm thử được.

• 
   Tính khả chuyển (đặc trưng của việc chuyển chương trình sang các máy tính khác)
  
• 
  - Có tính thích ứng: tính thích ứng.
  

- Tuân thủ các đặc tả chuyển: tính tuân thủ.

- Cho phép dễ dàng thay thế bằng phần mềm khác: khả năng thay thế.

1.8.3Quản lí tiến trình

• 
  Quản lí tiến trình được chia thành lập kế hoạch tiến độ và quản lí tiến trình. Ở đây, các đặc trưng của từng việc, và phương pháp được dùng cho chúng sẽ được giải thích.
  

• 
   Lập kế hoạch tiến trình
  
• 
  Việc phát triển hệ thống được hoàn thành qua nhiều tiến trình khác nhau. Một số công việc lớn phải mất nhiều năm để hoàn thành. Do đó, việc lập kế hoạch tiến độ chính xác là một khoản mục quản lí công việc quan trọng.
  
• 
  Nói riêng, các dự án phát triển mới bao gồm nhiều nhân tố không chắc chắn mà không thể nào được xác định dứt khoát trong pha lập kế hoạch tiến độ. Do đó, khi tiến độ công việc tiến lên, việc giải quyết linh hoạt cho các tình huống, như làm cho ngày chuyển giao sớm hơn (tuỳ theo tình huống) hay tối thiểu hoá chậm trễ, trở thành cần thiết.
  
• 
   Quản lí tiến trình
  
• 
  Quản lí tiến trình là việc quản lí sự diễn biến của công việc. Nó cần kiểm lại tiến độ công việc và tiến hành hành động nào đó đối với công việc có tiến độ bị chậm so với lịch biểu. Hiệu năng công việc phát triển hệ thống bị chia sẻ cho nhiều người. Do đó, sự chậm trễ của người này trong công việc dẫn tới sự chậm trễ trong tiến độ của dự án xem như một tổng thể. Hậu quả là, việc quản lí tiến trình thấu đáo là cần để làm tối thiểu tác động của chậm trễ cũng như để phát hiện ra vấn đề dễ nhất có thể được.
  
• 
  
  

• 
  Sơ đồ Gantt và PERT được dùng điển hình như các phương pháp lập kế hoạch tiến độ.
  
• 
   Sơ đồ Gantt
  
• 
  Sơ đồ Gantt cũng còn được gọi là "sơ đồ thanh."
  

• 
  
  
• 
  <Đặc trưng>
  
• 
  Nó cung cấp các biểu đồ dễ hiểu theo đó lịch biểu của từng việc được chỉ ra bằng đường ngang (thanh).
  
• 
  Trong sơ đồ này, thời gian bắt đầu và kết thúc theo lịch của từng phần việc và trạng thái hiện tại của chúng được biểu thị rõ ràng.
  
• 
  Ưu tiên của các phần việc không được vẽ ra.
  
• 
  Các mức độ theo đó sự chậm trễ trong từng phần việc ảnh hưởng tới các công việc khác không được vẽ ra.
  
• 
   PERT (Program Evaluation and Review Technique - Kĩ thuật kiểm điểm và đánh giá chương trình)
  
• 
  PERT cung cấp một kĩ thuật để sinh ra lịch biểu cho phần công việc (tiến độ) của một dự án, và thế rồi để quản lí chúng.
  

Hình 1-7-3 Ví dụ về biểu đồ PERT (biểu đồ thứ nhất của hai biểu đồ)

• 
  
  

  Hình 1-7-3 Ví dụ về biểu đồ PERT (Hình thứ nhất của biểu đồ)

  a tới h: mỗi từ chỉ công việc được thực hiện. Các chữ số: mỗi số đưa ra số ngày cần thiết cho công việc. Đường nét chấm (chỉ ra chỉ công việc yêu cầu được thực hiện

• 
  <Đặc trưng>
  
• 
  PERT có thể giải quyết việc phát triển các hệ thống qui mô lớn và phức tạp.
  
• 
  Nó tạo khả năng cho việc tính toán tổng số ngày cần thiết (thời kì tối thiểu cần thiết).
  
• 
  Thứ tự công việc cần được thực hiện được làm rõ ràng, tạo khả năng làm sáng tỏ các điểm quản lí quan trọng.
  
• 
  Số ngày được bao gồm trong từng mục như lề co dãn được dễ dàng tính ra.
  
• 
  Nó có thể được áp dụng cho các tính toán làm giảm chi phí phát triển và làm giảm số ngày cần cho công việc (dựa trên phương pháp đường găng CPM (Critical Path Method) hay các phương pháp khác).
  
• 
  
  
• 
  1. Xác định số ngày cần cho từng phần việc. Rồi kết quả được gắn lại với nhau trong bảng như trong Hình 1-7-4.
  
• 
  
  

  Hình 1-7-4 Ví dụ về bảng ước lượng công việc		Kí hiệu	Mục việc	Số ngày cần thiết	Các công việc phải được làm trước
  		a	Phân tích và xác định yêu cầu hệ thống	20	
  		b	Thiết kế hệ thống	20	a
  		c	Thiết kế vận hành chi tiết	30	b
  		d	Phân tích và xác định yêu cầu phần mềm	30	c
  		e	Thiết kế hệ thống phần mềm	20	d, l
  		f	Thiết kế phần mềm chi tiết	30	e, m
  		g	Lập trình	20	f
  		h	Kiểm thử móc nối phần mềm	20	g
  		i	Kiểm thử toàn bộ phần mềm	20	h
  		j	Kiểm thử móc nối hệ thống	20	i
  		k	Kiểm thử hệ thống	20	j
  		l	Thiết đặt phần cứng	50	b
  		m	Tạo dựng môi trường phát triển	10	l
  		n	Đào tạo và huấn luyện người liên quan	20	i

• 
  
  
• 
  2. Dựa trên bảng ước lượng công việc, biểu đồ PERT được vẽ trong Hình 1-7-5 (tính tới thứ tự công việc).
  
• 
  
  

• 
  
  
• 
  
  
• 
  3. Số ngày sau đây được quyết định tại từng nút.
  

  Thời gian móc nối sớm nhất có thể	:	Chỉ ra thời gian sớm nhất có thể, trước đó công việc không thể được bắt đầu.
  Thời gian móc nối muộn nhất có thể	:	Chỉ ra thời gian muộn nhất mà công việc phải được hoàn thành.

• 
  4. Đường đi được sinh ra bằng cách nối các nút, với từng nút mà thời gian sớm nhất có thể và thời gian muộn nhất có thể là như nhau (chỉ ra không được phép có lề co dãn nào) được gọi là "đường găng". Công việc trên đường này là quan trọng nhất cho việc quản lí.
  

• 
  Việc quản lí tiến trình được tiến hành theo hai quan điểm sau:
  
• 
  Định thời gian bắt đầu và kết thúc của từng phần việc
  
• 
  Trạng thái tiến độ của công việc cá nhân của từng người
  
• 
   Quản lí việc định thời gian bắt đầu và kết thúc của từng việc
  
• 
  Việc quản lí được tiến hành sao cho từng phần việc được bắt đầu như đã được xác định trong bản kế hoạch tiến độ và được kết thúc như được xác định bằng mọi phương pháp, bằng cách kiểm tra trạng thái tiến độ tức khắc của từng phần việc và bằng cách lấy những cách đo thích hợp dựa trên trạng thái đó.
  
• 
  Sau đây ta xét các lí do cho việc chậm trễ trong công việc:
  
• 
  Kĩ năng của kĩ sư liên quan không đủ.
  
• 
  Việc lập kế hoạch và đặt mục tiêu không được xem xét thích hợp.
  
• 
  Các vấn đề liên quan tới nhân sự (kể cả việc bố trí lại thành viên phát triển, việc chuyển một số thành viên sang vị trí khác, và một số người rời bỏ công ti)
  
• 
  Vấn đề ngân sách (kể cả công cụ hỗ trợ phát triển cần mua thực tế có thể không được mua).
  
• 
  Trục trặc phần cứng và/hoặc phần mềm
  
• 
  Khi chậm trễ trong công việc được phát hiện ra, người quản lí, như người lãnh đạo dự án, phải điều tra các biện pháp để giải quyết tình huống này và lấy những biện pháp cụ thể, như thay đổi tiến độ, sớm nhất có thể được.
  
• 
  Để tạo khả năng cho các biện pháp như vậy, mọi thành viên lực lượng lao động phải báo cáo trạng thái tiến độ của công việc của mình một cách đều đặn thông qua nhật kí công việc hay báo cáo công việc tuần. Nói riêng, khi một tình huống bất ngờ xuất hiện, người đó phải báo cáo sớm nhất có thể được.
  
• 
   Lập lịch cho từng thành viên lực lượng lao động
  
• 
  Việc lập lịch được dùng để phân bổ công việc của từng tiến trình cho từng thành viên lực lượng lao động, để quyết định thứ tự của từng phần việc được tiến hành, và để quản lí trạng thái tiến độ công việc trên cơ sở hàng ngày. Việc lập lịch cũng có hiệu quả để làm cho thời gian chuyển giao sớm hơn và tối thiểu việc chậm trễ.
  
• 
  
  
• 
  Ví dụ Thiết kế ngoài, cho việc thiết kế đại cương một hệ thống, bao gồm nhiều phần việc, trong đó một số lớn các kĩ sư hệ thống (SEs) có tham dự vào. Trong ví dụ này, việc lập lịch trở thành như sau khi được xét theo quan điềm người lãnh đạo và quan điểm của thành viên lực lượng lao động, tương ứng:
  
• 
  
  
• 
  Công việc thiết kế hệ thống được chia thành một số việc nhỏ.
  
• 
  Mỗi việc được phân bổ cho từng thành viên tuỳ theo mức độ kĩ năng của người đó.

  Việc lập lịch cho từng thành viên (từng công việc) được thực hiện.

  Hướng dẫn phân bổ công việc được trao cho từng thành viên.

  Việc hoàn thành của từng công việc được kiểm tra bằng cách đọc nhật kí công việc hay báo cáo tuần của từng thành viên.

  Tiến hành những biện pháp linh hoạt, như thay đổi kế hoạch nếu cần, khi phát hiện ra chậm trễ trong công việc.
  

• 
  
  
• 
  1. Người đó tự quản lí mình bằng cách so sánh trạng thái tiến độ công việc với lịch công việc đã được phân bổ và cố gắng giữ thời gian kết thúc như kế hoạch.
  
• 
  2. Người đó báo cáo về trạng thái tiến độ công việc thông qua nhật kí công việc hay báo cáo tuần, bên cạnh việc báo cáo khi công việc hoàn thành xong.
  
• 
  
  
• 
  Như đã mô tả ở trên, quản lí tiến trình được tiến hành bằng việc tổ hợp  kế hoạch tiến trình thô (quyết định ngày tháng bắt đầu công việc và kết thúc công việc) và  lập lịch chi tiết.
  
• 
  Nói riêng, việc báo cáo cho người quản lí là rất quan trọng cho cả  và .
  
• 
  Hình 1-7-6 chỉ ra mối quan hệ giữa kế hoạch và báo cáo.
  
• 
  
  

  Hình 1-7-6 Quan hệ giữa kế hoạch và báo cáo			Mức trung	Mức trung	Mức thấp
  		Kế hoạch	 Báo cáo bao quát dự án như một toàn thể được soạn ra	 Tạo ra kế hoạch tiến độ cho từng hệ con	 Lịch công việc cho từng thành viên lực lượng lao động được tạo ra.
  		Báo cáo	 Báo cáo hoàn thành công việc	 Báo cáo hoàn thành tiến trình	 Báo cáo công việc  Báo cáo công việc theo tuần

• 
  
  

1.8.4Năng suất phần mềm

• 
  Để đánh giá năng suất phần mềm, phải đánh giá được qui mô phần mềm. Việc phát triển phần mềm bao gồm nhiều cái ra khác nhau tuỳ theo từng tiến trình, như các đề án, đặc tả yêu cầu, đặc tả thiết kế, đặc tả chương trình, và chương trình nguồn. Tuy nhiên, phần nhiều trong chúng được tạo ra bằng công việc kiểu thủ công, tuỳ thuộc phần lớn vào kinh nghiệm và cảm giác con người. Do đó, việc ước lượng chi phí cũng phụ thuộc chủ yếu vào kinh nghiệm và cảm giác. Để cải thiện tình hình này, người ta đề nghị dùng kĩ nghệ phần mềm. Sau đó nhiều phương pháp ước lượng chi phí đã được đề nghị, và một số trong chúng bây giờ đang được dùng.
  

(1) Đại cương về ước lượng

• 
  Chẳng hạn, Hình 1-7-7 chỉ ra ví dụ về ước lượng khi xây nhà.
  

  Hình 1-7-7 Ví dụ ước lượng chi phí làm nhà

  Không gian sàn Ước lượng chi phí nhà được so sánh dễ dàng

• 
  
  
• 
  Mái, cửa và cửa sổ tất cả đều thấy được. Do đó, nếu bản đại cương được thiết kế, thì chi phí có thể được ước lượng (dựa trên không gian sàn nhà và các nhân tố khác).
  
• 
  Tuy nhiên, tệp, cơ sở dữ liệu và chương trình tất cả lại không thấy được. Do đó, các ước lượng trong pha thiết kế chi tiết trở thành khác biệt lớn với các ước lượng trong pha lập kế hoạch cơ sở. Hậu quả là, ước lượng về phát triển hệ thống nên được tiến hành trong nhiều pha được mô tả như sau:
  
• 
  1. Trong pha lập kế hoạch cơ sở (khi việc hệ thống hoá được lập kế hoạch)
  
• 
  2. Trong pha thiết kế ngoài (khi việc phân hoạch thành các hệ con được tiến hành)
  
• 
  3. Trong pha thiết kế trong (khi chương trình được thiết kế).
  

(2) Cách làm ước lượng

• 
  Có các phương pháp sau đây để ước lượng tỉ lệ phát triển:
  

- Ước lượng dựa theo dữ liệu quá khứ

- Ước lượng dựa theo số dòng mã

- Phương pháp nhiệm vụ chuẩn

- Phương pháp FP (điểm chức năng)

- Các mô hình ước lượng đa dạng (mô hình COCOMOl, v.v.)

• 
  Trong phần sau đây, từng phương pháp được nhắc tới trên sẽ được mô tả ngắn gọn:
  
• 
   Ước lượng dựa trên dữ liệu quá khứ
  
• 
  Trong phương pháp này, các ước lượng về hệ thống được phát triển và suy ra dựa trên dữ liệu thực của hệ thống tương tự đã xây dựng trong quá khứ. Có hai cách để làm ước lượng.
  
• 
  Toàn bộ tiến trình phát triển hệ thống được phân hoạch thành một số bước, và các ước lượng được suy dẫn ra dựa trên dữ liệu thực cho công việc tương tự.
  
• 
  Hệ thống được phân hoạch thành một số mô đun chương trình, và các ước lượng được suy ra dựa trên dữ liệu thực tế cho các mô đun chương trình tương tự.
  
• 
  <Đặc trưng>
  
• 
  Với hệ thống tương tự trong quá khứ, các lỗi cơ sở khó mà bị bao hàm vào.
  
• 
  Nhiệm vụ ước lượng là tương đối đơn giản.
  
• 
  Số lỗi trong các ước lượng trở nên lớn hơn nếu hệ thống quá khứ thích hợp không được chọn cho việc ước lượng.
  
• 
  Việc áp dụng phương pháp này là không thể được nếu không có hệ thống tương tự trong quá khứ.
  
• 
   Phương pháp dựa trên LOC
  
• 
  Phương pháp dựa trên LOC là hay được dùng nhất làm phương pháp cho việc ước lượng kích cỡ phát triển. Với phương pháp này, kích cỡ phát triển được ước lượng bằng số dòng mã (chẳng hạn, LOC, XXXX kilo tương đương COBOL), và dựa trên dữ liệu này, khối lượng tài nguyên cần thiết được ước lượng ra.
  
• 
  
  
• 
  1. Hệ thống được diễn tả như một tập các mô đun chương trình
  
• 
  Các chức năng hệ thống được phân hoạch thành các mô đun chương trình, với mối quan hệ giữa chúng được chỉ ra bằng biểu đồ khối cấu trúc hay các phương tiện khác.
  
• 
  2. Tính toán kích cỡ của từng chương trình
  
• 
  Số các LOC trong từng mô đun chương trình trong biểu đồ được ước lượng. Rồi tổng số các LOC được tính toán.
  
• 
  3. Ước lượng nhân lực cho tất cả các chương trình cần làm.
  
• 
  Tổng số các LOC được chuyển thành tổng nhân lực, như dữ liệu và người-tháng (số người cần thiết nhân với số tháng cần thiết). Chẳng hạn, nếu việc phát triển hệ thống cần nỗ lực làm việc 2 năm của 20 người, thì nhân lực là 20 người x 24 tháng = 480 người-tháng.
  
• 
  4. Ước lượng trên cơ sở tiến trình
  
• 
  Khối lượng nhân lực được phân bổ cho từng tiến trình, như lập kế hoạch cơ sở và các thiết kế khác nhau, với số phần trăm phân bổ được quyết định dựa trên dữ liệu quá khứ.
  
• 
  5. Ước lượng về nhân lực gián tiếp
  
• 
  Trọng số cho nhân lực đối với các công việc KNPM, như phân tích và thiết kế hệ thống, và trọng số cho nhân lực đối với công việc hành chính, sẽ được quyết định.
  
• 
  6. Tổng nhân lực được ước lượng
  
• 
  Tổng nhân lực được tính bằng việc kết tập dữ liệu nhân lực cho từng tiến trình.
  
• 
  <Đặc trưng>
  
• 
  Nó cung cấp phương pháp tiêu biểu nhất.
  
• 
  Nếu có các chuẩn rõ ràng để ước lượng chương trình LOC và để chuyển chúng thành khối lượng nhân lực, thì tính toán được bao hàm là khá đơn giản.
  
• 
  Điều tiên quyết là đại cương về các chức năng của chương trình cần phát triển phải được hiểu thấu.
  
• 
   Phương pháp dựa trên nhiệm vụ chuẩn
  
• 
  Với phương pháp dựa trên nhiệm vụ chuẩn, công việc được chia ra trên cơ sở cái ra hay trên cơ sở xử lí bằng WBS (Work Breakdown Structure - Cấu trúc phân việc). Sau đó, ước lượng chi tiết được thực hiện cho từng đơn vị, và ước lượng kết quả được tích luỹ theo cách từ dưới lên. Tham khảo 1.1.2 về WBS.
  
• 
  
  
• 
  
  
• 
  
  
• 
  1. Kiểm tra đầu ra và công việc được yêu cầu
  
• 
  Hệ thống được chia ra thành một cấu trúc phân cấp dựa trên WBS, và tất cả các đầu ra cần được phát triển trong dự án được liệt kê ra. Sau đó, tất cả công việc cần làm để sinh ra những cái ra này được chọn lấy.
  
• 
  2. Kích cỡ của từng công việc được chuyển thành khối lượng nhân lực.
  
• 
  Khối lượng nhân lực cần cho từng đơn vị công việc được chọn được đưa ra ước lượng theo những chuẩn nào đó, như dữ liệu thực tế cho chuẩn đã có tác dụng trong quá khứ.
  
• 
  3. Kết tập toàn bộ nhân lực
  
• 
  Khối lượng nhân lực được ước lượng cho từng công việc được tính tổng lại.
  
• 
  <Đặc trưng>
  
• 
  Với phương pháp này, việc ước lượng được thực hiện sau khi công việc được chia thành mức cái ra chi tiết hay mức xử lí, rồi các ước lượng được tích luỹ theo cách từ dưới lên. Do đó, nền cho các ước lượng được làm rõ ràng.
  
• 
  Nếu có phát sinh sai biệt thì việc nhận diện nguyên nhân là dễ dàng.
  
• 
  Dữ liệu thực tế cho công việc chuẩn là cần có. Thêm vào đó, công việc ước lượng đòi hỏi nhiều nỗ lực.
  
• 
   Phương pháp FP (Function Point - điểm chức năng)
  
• 
  Với phương pháp (điểm chức năng), từng chức năng được đưa vào trong hệ thống sẽ được diễn đạt định lượng bằng một phương pháp nào đó, và do vậy dữ liệu được biểu diễn theo định lượng được dùng như cách đo ước lượng (xem Hình 1-7-8).
  
• 
  
  

  Hình 1-7-8 Ví dụ về phương pháp FP

• 
  Phương pháp này khác cơ bản với ba phương pháp  tới  đã mô tả trên trong việc dùng từng chức năng được cung cấp cho khách hàng xem như đơn vị đo (hoặc phương pháp này được gọi là phương pháp ước lượng hướng khách hàng). Chẳng hạn, các chức năng sau đây được người dùng sử dụng được lựa làm đơn vị để diễn đạt về định lượng.
  
• 
  
  
• 
  
  
• 
  <Đơn vị được dùng như chuẩn>
  

- Cái vào

- Cái ra

- Tệp và cơ sở dữ liệu (dữ liệu được lưu giữ nội bộ)

- Yêu cầu về tệp và cơ sở dữ liệu

- Giao diện với hệ thống khác

• 
  
  
• 
  1. Kiểm các chức năng ("đơn vị được dùng làm chuẩn" đã được mô tả ở trên) được hệ thống cung cấp
  
• 
  2. Các chức năng được lựa trong Khoản mục 1 trên, được phân lớp thành các loại "đơn giản," "trung bình" hay "phức tạp." Sau đó, một trọng số được gắn cho từng loại dựa trên những chuẩn nào đó.
  
• 
  
  
• 
  3. Các giá trị được cho trong Khoản mục 2 trên được kết tập (vậy dữ liệu suy dẫn thiết lập nên FP trước khi việc điều chỉnh được thực hiện).
  
• 
  4. Các hệ số chuyên hệ thống được suy ra tuỳ theo đặc trưng của hệ thống đích.
  
• 
  5. FP cuối cùng được tính toán bằng việc nhận dữ liệu từ Khoản mục 3 ở trên, với dữ liệu từ Khoản mục 4 ở trên.
  
• 
  6. Giá trị FP được chuyển thành khối lượng nhân lực dự án.
  
• 
  <Đặc trưng >
  
• 
  Dữ liệu dễ hiểu với người dùng, bởi vì việc ước lượng được thực hiện cho các khoản mục thấy được với người dùng.
  
• 
  Việc điều chỉnh được thực hiện dựa trên dữ liệu thực tế được tích luỹ trong quá khứ. Do đó, việc tích luỹ dữ liệu là cần thiết.
  
• 
  Cần có tiêu chuẩn đánh giá chuẩn hoá trong việc áp dụng phương pháp ước lượng này.
  
• 
   Mô hình COCOMO (COnstruction COst MOdel)
  
• 
  Mô hình COCOMO, một phương pháp ước lượng do Boehm đề xuất, là phù hợp cho việc ước lượng các hệ thống cỡ trung tới cỡ lớn.
  
• 
  Với mô hình COCOMO, hệ thống được phân lớp dựa trên ba mốt sau. Sau đó với từng mốt, nhân lực phát triển tổng cộng và thời kì phát triển được tính toán từ số các câu lệnh được dự kiến vào lúc hệ thống được trao cho người dùng.
  
• 
  
  

- Mốt tổ chức (phát triển hệ thống cỡ nhỏ)

- Mốt nửa nhúng (phát triển hệ thống cho vận hành bình thường)

- Hệ thống nhúng (phát triển các hệ thống lớn và có ràng buộc dư thừa)

• 
  <Đặc trưng>
  
• 
  - Bên cạnh việc được chính nó dùng, phương pháp này cũng còn được dùng để kiểm các ước lượng theo các phương pháp khác.
  
• 
  - Cần tích luỹ và phân tích dữ liệu thực tế bao gồm dữ liệu nhân lực phát triển cho các hệ thống đa dạng.
  
• 
  
  

1.8.5Tổ chức phát triển

• 
  Có nhiều điểm đóng góp cho sự thành công của việc phát triển hệ thống, kể cả các khoản mục liên quan tới quản lí công việc đa dạng như sau:
  

- Sự tham dự tích cực của người dùng (thiết lập tổ chức phát triển)

- Quản lí tiến trình kĩ lưỡng và quản lí tiến trình của công việc từng người

- Quản lí chất lượng hệ thống kĩ lưỡng

• 
  Việc phát triển hệ thống qui mô lớn cần thời gian phát triển lâu (đôi khi đến nhiều năm), và đòi hỏi số tiền và tài nguyên nhân lực rất lớn.
  
• 
  Tuy nhiên, không phải bi quan rằng việc phát triển hệ thống thất bại trong pha lập kế hoạch cơ sở hay pha thiết kế hay, mặc dầu việc phát triển được hoàn tất, chất lượng lại quá nghèo nàn không dùng được trong vận hành thực tế.
  
• 
  Một cách tự nhiên, công việc phát triển được quản lí bởi một người quản lí, chẳng hạn, người quản lí dự án. Tuy nhiên, việc quản lí đúng công việc của riêng từng thành viên phát triển và tạo ra cái ra chất lượng cao là nhân tố quan trọng dẫn việc phát triển hệ thống tới thành công.
  
• 
  Điều quan trọng thứ nhất để đưa việc phát triển hệ thống tới thành công là thiết lập một tổ chức phát triển vững chắc. Làm tiến độ công việc đúng theo lịch phát triển hệ thống (lịch mức cao nhất) đã tạo ra trong pha lập kế hoạch cơ sở là điều tiên quyết lớn nhất cho sự thành công. Hơn nữa, liệu công việc có tiến hành trôi chảy hay không cũng có thể được nói là tuỳ thuộc phần lớn vào công việc hợp tác của các thành viên lực lượng lao động.
  

(1) Các phong cách tổ chức

• 
  Kiểu phong cách tổ chức phát triển nào nên được dùng còn tuỳ theo qui mô phát triển hay những người tạo nên lõi cho việc phát triển. Tuy nhiên, sự tham dự của người dùng là không thể thiếu được trong bất kì tổ chức nào. Trong nhiều việc phát triển hệ thống thành công, tổ chức của người dùng tham dự vào việc lập kế hoạch cơ sở và thiết kế ngoài.
  
• 
  Hơn nữa, việc phát triển hệ thống thường được tiến hành trong sự hợp tác với các công ti phát triển bên ngoài. Chẳng hạn, việc khởi thảo cho tới pha thiết kế được thực hiện nội bộ, còn việc lập trình thì thuê khoán ngoài với các công ti khác.
  
• 
  Xem như một ví dụ về tổ chức phát triển, Hình 1-7-9 chỉ ra một tổ chức cho dự án qui mô nhỏ, trong khi Hình 1-7-10 nêu ra một tổ chức cho dự án qui mô lớn.
  

Hình 1-7-9 Ví dụ về tổ chức phát triển qui mô nhỏ

• 
  
  

Hình 1-7-10 Ví dụ về tổ chức phát triển qui mô lớn

(2) Tổ chức phát triển

• 
  Tổ chức phát triển nhận các yêu cầu hệ thống hoá từ người dùng, và tiến hành công việc về lập kế hoạch cơ sở, các kiểu thiết kế, lập trình và các kiểu kiểm thử. Gần đây, trong nhiều trường hợp, các tổ dự án nội bộ thực hiện công việc về lập kế hoạch cơ sở và thiết kế, còn lập trình và kiểm thử được uỷ quyền cho các công ti phát triển phần mềm bên ngoài. Tuy nhiên, tổ chức phát triển vẫn tiến hành công việc kiểm nhận sau khi kiểm thử đã hoàn tất.
  
• 
   Các kiểu tổ chức phát triển
  
• 
  Nhiều việc phát triển hệ thống được tiến hành như các dự án. Định nghĩa của NASA (National Aeronautics and Space Administration) về dự án là "Các nhiệm vụ được tiến hành trong nhiều tổ chức kéo dài từ một tới năm năm và có liên quan lẫn nhau." Nói cách khác, dự án chỉ ra một tổ chức với các mục đích xác định kéo dài trong một khoảng thời gian giới hạn.
  
• 
  
  

Hình 1-7-11 Ví dụ về tổ chức phát triển (tổ cấp bậc)

• 
  
  
• 
  
  
• 
  
  
• 
  
  
• 
  
  
• 
  
  
• 
  
  
• 
  
  
• 
  Có ba kiểu tổ dự án điển hình.
  
• 
  - Tổ người lập trình chính
  

- Tổ chuyên gia

- Tổ phân cấp

• 
  a. Tổ người lập trình chính
  
• 
  Tổ người lập trình chính là một tổ dự án bao gồm một số tương đối nhỏ tối đa mười thành viên, với người lập trình chính có hoàn toàn trách nhiệm thực hiện quyền lãnh đạo trong việc phân bổ công việc cho từng thành viên một cách rõ ràng và làm tăng năng suất và chất lượng.
  
• 
  
  

  Hình 1-7-12 Ví dụ về tổ người lập trình chính

• 
  
  
• 
  < Đặc trưng>
  
• 
  Dự án qui mô tương đối nhỏ có thể chấp nhận kiểu tổ chức tổ này.
  
• 
  Đặc trưng có ý nghĩa nhất của tổ chức này là sự tồn tại của người lập trình dự phòng và thủ thư.
  
• 
  Nó phù hợp cho việc rèn luyện người lãnh đạo (người lập trình chính phải chịu gánh nặng trách nhiệm).
  
• 
  Nó có khuynh hướng gây ra sự suy giảm tinh thần của người lập trình.
  
• 
  b. Tổ chuyên gia
  
• 
  Tổ chuyên gia là một kiểu sửa đổi của kiểu tổ người lập trình chính, và bao gồm một người lập trình chính cùng nhiều chuyên gia kĩ thuật.
  
• 
  
  

  Hình 1-7-13 Ví dụ về tổ chuyên gia

• 
  
  
• 
  <Đặc trưng>
  
• 
  Người lập trình chính tạo ra tất cả các chương trình.
  
• 
  Các chuyên gia kĩ thuật chịu trách nhiệm các lĩnh vực đặc biệt (như công cụ phát triển, kiểm thử, tài liệu, cơ sở dữ liệu, v.v.) giúp cho công việc của người lập trình chính, mở rộng khả năng của người lập trình tới mức tối đa có thể.
  
• 
  Điều bản chất là các thành viên có kĩ năng mức cao.
  
• 
  c. Tổ phân cấp
  
• 
  Tổ phân cấp bao gồm một người quản lí dự án, nhiều người quản lí dự án và các thành viên lực lượng lao động.
  
• 
  
  

  Hình 1-7-14 Ví dụ về tổ phân cấp

• 
  <Đặc trưng>
  
• 
  - Kiểu tổ chức tổ này được sử dụng rộng rãi nhất ở Nhật.
  
• 
  - Nó được chấp nhận trong việc phát triển phần mềm qui mô tương đối lớn.
  
• 
  - Trao đổi trở nên kém thích hợp hơn, nếu so với tổ người lập trình chính.
  
• 
   Vai trò của các thành viên tổ
  
• 
  a. Người chịu trách nhiệm tổ chức phát triển (người quản lí dự án)
  
• 
  Trong nhiều trường hợp, người chịu trách nhiệm của tổ chức phát triển trở thành người quản lí dự án. Người quản lí, tại một ví trí quan trọng, hoàn toàn chịu trách nhiệm cho dự án phát triển.
  
• 
  Người quản lí dự án phải không chỉ có kĩ năng công nghệ thông tin mức cao, mà còn phải có khả năng quản lí dự án và khả năng lập kế hoạch. Thêm vào đó, việc duy trì trao đổi đúng đắn bên trong công ti và với các bên ở ngoài công ti là một vai trò quan trọng của người quản lí.
  
• 
  
  
• 
  Lập kế hoạch, soạn thảo kế hoạch, thực hiện và ước lượng dự án.
  
• 
  Trao đổi với người dùng và các tổ chức có liên quan (kể cả các bên ở ngoài công ti)
  
• 
  Truyền sinh lực cho công việc dự án (kể cả việc triển khai nhân sự và truyền quyền lực)
  
• 
  Công việc quản lí khác
  
• 
  b. Người lãnh đạo dự án
  
• 
  Người lãnh đạo dự án đóng vai trò phân bổ người quản lí dự án, đặt hoạt động tổ vào trật tự, hay hành động như người ở giữa các thành viên lực lượng lao động và người quản lí dự án.
  
• 
  Một tổ chức được người lãnh đạo dự án điều khiển được gọi là "tổ dự án con", thực hiện công việc phát triển thực tại hay công việc hỗ trợ phát triển (kĩ thuật, kiểm thử, chuẩn hoá hay các công việc khác).
  
• 
  
  

  Hình 1-7-15 Ví dụ về tổ dự án con

  Công việc phát triển dựa trên hệ con được thực hiện Công việc hỗ trợ phát triển được thực hiện

• 
  c. Thành viên
  
• 
  Được chỉ dẫn bởi người lãnh đạo dự án, các thành viên thực hiện công việc phát triển thực tế (thiết kế, lập trình c.c..) hay công việc hỗ trợ phát triển.
  

(3) Tổ chức người dùng

• 
  Việc phát triển hệ thống được tiến hành theo yêu cầu của tổ chức người dùng, và tổ chức người dùng dùng hệ thống đã được phát triển. Do đó, mặc dầu tổ chức phát triển thực hiện việc phát triển hệ thống, việc phát triển hệ thống vẫn không thể thành công được nếu không có sự hợp tác của tổ chức người sử dụng.
  
• 
  Hình 1-7-16 chỉ ra một cấu trúc tổ chức đơn giản của tổ chức người dùng.
  

  Hình 1-7-16 Cấu trúc tổ chức đơn giản hoá của tổ chức người dùng

• 
   Người chịu trách nhiệm của tổ chức người dùng
  
• 
  Người chịu trách nhiệm của tổ chức người dùng có quyền lớn nhất trong mọi pha từ khía cạnh ngân sách tới việc thúc đẩy dự án phát triển hệ thống hiện tại. Với người chịu trách nhiệm của tổ chức người dùng, người đó cũng được yêu cầu rằng người đó phải làm nỗ lực tối đa để làm tăng tỉ lệ hiệu quả-đầu tư bằng việc thực hiện nhiều kế hoạch khác (như tổ chức các khoá huấn luyện) như người lãnh đạo.
  
• 
   Tổ chức khởi xướng phát triển
  
• 
  Tổ chức khởi xướng phát triển được tổ chức với những người có trách nhiệm (những người ở vị trí quản lí) trong tổ chức người dùng làm cốt lõi, và đưa ra sự chấp thuận các cái ra từ việc phát triển hệ thống. Tuy nhiên điều đó không liên quan tới chi tiết hệ thống
  
• 
   Người dùng
  
• 
  Người dùng thực tế sử dụng hệ thống. Vậy, người dùng nên tham gia vào việc phát triển hệ thống cho lời khuyên về nhiều hoạt động đa dạng. Do đó, người dùng tham gia nên quen các tiến trình nghiệp vụ.
  

Каталог: 2010
2010 -> Giới thiệu chung Kết quả Kinh tế của Việt Nam
2010 -> Học thêm Hóa học 11 axit bazơ muối câu 1
2010 -> CHÍnh phủ  CỘng hoà XÃ HỘi chủ nghĩa việt nam
2010 -> Danh mục các loại giấy tờ VỀ tạo lập nhà Ở ĐẤT Ở làm cơ SỞ pháp lý ĐỂ CẤp giấy chứng nhậN
2010 -> Ủy ban nhân dân cộng hòa xã HỘi chủ nghĩa việt nam thành phố CẦn thơ Độc lập Tự do Hạnh phúc
2010 -> BỘ TƯ­ pháp cộng hoà XÃ HỘi chủ nghĩa việt nam
2010 -> PHÁt triển nông thôN
2010 -> BỘ chính trị ĐẢng cộng sản việt nam
2010 -> CHÍnh phủ CỘng hoà XÃ HỘi chủ nghĩa việt nam

tải về 1.95 Mb.

Chia sẻ với bạn bè của bạn: