Công Nghệ Phần Mềm

3 Xác định những nguồn nào cần để thực hiện từng nhiệm vụ 4 Xác định thời gian cần sử dụng nguồn của từng nhiệm vụ 5 Xác định thời điểm bắt đầu và kết thúc của từng nhiệm vụ 6 [r]

Nhập môn

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

(Introduction to Software Engineering)

Department of Software Engineering Faculty of Information Technology

Hanoi University of Technology

Cấu trúc mơn học

• 45 tiết + Đồ án mơn học

• Cần kiến thức CNTT • Cung cấp nguyên lý chung

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

• Cung cấp kiến thức để học môn

chuyên ngành hẹp Phân tích thiết kế phần mềm, Xây dựng đánh giá

Cấu trúc mơn học (tiếp)

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

– Giới thiệu chung CNHPM (3 buổi) – Quản lý dự án PM (2b)

– Yêu cầu người dùng (1b)

– Thiết kế lập trình (2b) – Kiểm thử bảo trì (2b)

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

Tài liệu tham khảo

• R Pressman, Software Engineering: A Practioner’s

Approach 5th Ed., McGraw-Hill, 2001

• R Pressman, Kỹ nghệ phần mềm Tập 1, 2,

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

Phần I

Giới thiệu chung CNHPM

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

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

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

1.3 Các khái niệm

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

1.5 Thế phần mềm tốt ?

1.1 Định nghĩa chung phần

mềm

• Phần mềm (Software - SW)

khái niệm đối nghĩa với phần cứng

(Hardware - HW), nhiên, đây khái niệm tương đối

• Từ xưa, SW thứ cho khơng

hoặc bán kèm theo máy (HW)

• Dần dần, giá thành SW ngày cao

Các đặc tính SW HW

HW • Vật “cứng” • Kim loại • Vật chất • Hữu hình

• Sản xuất cơng nghiệp

bởi máy móc

• Định lượng

SW • Vật “mềm”

• Kỹ thuật sử dụng • Trừu tượng

• Vơ hình

• Sản xuất

người

Định nghĩa 1: Phần mềm là

• Các lệnh (chương trình máy tính)

được thực cung cấp chức năng kết mong muốn

• Các cấu trúc 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 cách sử

SW đối nghĩa với HW

• Vai trò SW ngày thể trội

• Máy tính 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), chủ đề cốt lõi, trung tâm HTMT

Định nghĩa

Trong hệ thống máy tính, trừ bỏ các thiết bị loại phụ kiện phần cịn lại phần mềm (SW)

• Nghĩa hẹp: SW dịch vụ chương trình để

tăng khả xử lý phần cứng máy tính (như hệ điều hành - OS)

• Nghĩa rộng: SW tất kỹ thuật ứng

SW theo nghĩa rộng

• Khơng chỉ SW SW ứng dụng • Phải gồm khả năng, kinh nghiệm thực

tiễn kỹ kỹ sư (người chế phần mềm): Know-how of Software

Engineer

• Là tất kỹ thuật làm cho sử dụng

Phần mềm ?

Nhóm Kỹ thuật, Phương pháp

luận

Nhóm

chương trình Nhóm tư liệu

Nhóm kỹ thuật, phương pháp luận

• Các khái niệm trình tự cụ thể hóa hệ

thống

• Các phương pháp tiếp cận giải vấn đề

• Các trình tự thiết kế phát triển chuẩn

hóa

• Các phương pháp đặc tả yêu cầu, thiết kế hệ

• Là phần giao diện với phần cứng, tạo thành từ

nhóm lệnh thị cho máy tính biết trình tự thao tác xử lý liệu

• Phần mềm bản: với chức 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 xử lý phần cứng (ví dụ 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 (quản lý, kế tốn, ), phần mềm đóng gói, phần mềm người dùng,

Nhóm tư liệu

• Những tư liệu hữu ích, có giá trị cao

rất cần thiết để phát triển, vận hành bảo trì phần mềm

• Để chế phần mềm với độ tin cậy cao

Những yếu tố khác

• Sản xuất phần mềm phụ thuộc nhiều vào

con người (kỹ sư phần mềm) Khả hệ thống hóa trừu tượng, khả lập trình, kỹ năng cơng nghệ, kinh nghiệm làm việc, tầm bao quát, : khác người

• Phần mềm phụ thuộc nhiều vào ý tưởng (idea)

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

1.2.1 Phần mềm nhìn từ cấu trúc phân cấp

• Cấu trúc phần mềm cấu trúc phân cấp

(hierarchical structure): mức hệ thống (system), hệ thống (subsystems)

• Dưới hệ thống chương trình • Dưới chương trình Modules

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

System

Subsystem Subsystem

Program Program

Module Module Subroutine

Master files

Temporary files

Job unit

Jobstep unit

Member unit

1.2.2 Phần mềm nhìn từ cấu trúc thủ tục

• Hai yếu tố cấu thành phần mềm

– Phương diện cấu trúc – Phương diện thủ tục

• Cấu trúc phần mềm: biểu thị kiến trúc

chức mà phần mềm có điều kiện phân cấp chức (thiết kế cấu trúc)

• Thiết kế chức năng: theo chiều đứng (càng sâu

Cấu trúc phần mềm

Fuction A

Function B Function C

Function D Function E Function F

Cấu trúc chiều ngang

Thủ tục (procedure) phần mềm

• Là quan hệ trình tự mà phần

mềm có

• Thuật tốn với 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ị chức có

trong phần mềm trình tự thực chú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): chuẩn

mực để chế tạo phần mềm với tiêu định tính

– Các phương pháp kỹ thuật (Techniques):

trình tự cụ thể để chế tạo phần mềm cách tiếp cận khoa học mang tính định lượng

Các khái niệm

(Software concepts)

• Khái niệm tính mơđun (modularity

concept)

• Khái niệm chi tiết hóa dần 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, liệu

• Khái niệm che giấu thơng tin (information

hiding concept)

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

Tính Mơđun Chi tiết hóa dần

Trừu tượng hóa (Che giấu t.tin)

Phân tích cấu trúc Thiết kế cấu trúc Lập trình cấu trúc Dữ liệu trừu tượng

1.3.1 Tính mơđun (Modularity)

• Là khả phân chia phần mềm thành

môđun ứng với chức năng, đồng thời cho phép quản lý tổng thể: khái niệm phân chia 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ệ môđun: qua đối số

Chuẩn phân chia mơđun

Tính độc lập

dần

Điều khiển

SW Phân chia chiều rộng

Ph â n c hi a ch iều sâu

Cấu trúc rộng chiều ngang

1.3.2 Chi tiết hóa bước

Cách tiếp cận từ xuống (top-down approach) Chi tiết hóa bước Thế giới bên

Đặc tả yêu cầu

Trừu tượng hóa mức cao: Thế giới bên ngồi,

trạng thái chưa rõ ràng

Ví dụ: Trình tự giải vấn đề từ mức thiết kế chương trình đến mức lập trình

• Bài tốn: từ nhóm N số khác

tăng dần, tìm số có giá trị K

(nhập từ vào) in vị trí

• Giải bước từ khái niệm đến chi tiết

hóa từng câu lệnh ngơn ngữ lập trình nào đó

• Chọn giải thuật tìm kiếm nhị phân (pp

Cụ thể hóa thủ tục qua chức năng

Bài toán cho Nhập giá trị K

Nhận giá trị nhóm N số

Cụ thể hóa bước

Tìm kiếm giá trị (pp nhị phân)

Xác lập phạm vi mảng số

Lặp lại xử lý tìm kiếm giá trị K phạm vi tìm kiếm

Tìm vị trí phân đôi mảng So sánh K với giá trị

Lặp lại tìm kiếm K

Mức mơ tả chương trình (bằng PDL)

Bắt đầu Đọc K

Nhận giá trị cho mảng chiều A(I), (I =1, 2, ,.N) MIN =

MAX = N

DO WHILE (Có giá trị K khơng, MIN > MAX) Lấy MID = (MIN + MAX) /

IF A(MID) > K THEN MAX = MID - ELSE

IF A(MID) < K THEN MIN = MID + ELSE

In giá trị MID ENDIF

1.3.3 Khái niệm Che giấu thơng tin

• Để phân rã phần mềm thành 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 định thiết kế cho mơđun ẩn kín đối với mơđun khác” [Parnas1972]

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 chi tiết mức thấp liên quan

• mức trừu tượng

– Trừu tượng thủ tục: dãy thị với chức

đặc thù giới hạn

– Trừu tượng liệu: tập hợp liệu mô tả đối

tượng liệu

– Trừu tượng điều khiển: Cơ chế điều khiển chương

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

• Là hàng hóa vơ hình, khơng nhìn thấy

• Chất lượng phần mềm: khơng mịn mà có

xu hướng tốt lên sau lần có lỗi (error/bug) được phát sửa

• Phần mềm vốn chứa lỗi tiềm tàng, theo quy

mô lớn khả chứa lỗi cao

• Lỗi phần mềm dễ phát người

Đặc tính chung phần mềm (tiếp)

• Chức 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 sóng thay đổi phần mềm • Phần mềm vốn chứa ý tưởng sáng tạo

tác giả/nhóm làm

• Cần khả “tư nhị phân” xây

dựng, phát triển phần mềm

1.5 Thế phần mềm tốt ?

Hiệu suất xử lý

Các tiêu Tính dễ hiểu

Yếu tố khái niệm phần mềm

tốt

1.5.1 Các chỉ tiêu

• Phản ánh yêu cầu người dùng (tính

hiệu - effectiveness)

• Chứa lỗi tiềm tàng

• Giá thành không vượt giá ước lượng

ban đầu

• Dễ vận hành, sử dụng

1.5.2 Hiệu suất xử lý cao

• Hiệu suất thời gian tốt (efficiency):

– Độ phức tạp tính tố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)

1.5.3 Tính dễ hiểu

• Kiến trúc 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ả u cầu, điều kiện

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

• Phần mềm hệ thống (System SW)

• Phần mềm thời gian thực (Real-time SW) • Phần mềm nghiệp vụ (Business SW)

• Phần mềm tính tố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 Web (Web-based SW)

Chương 2:

Khủng hoảng phần mềm (Software Crisis)

2.1 Khủng hoảng phần mềm ?

2.2 Những vấn đề (khó khăn)

2.1 Khủng hoảng phần mềm gì?

• 10/1968 Hội nghị NATO chuyên gia phần mềm đã đưa thuật ngữ “Khủng hoảng phần mềm” (Software crisis) Qua hàng chục năm, thuật ngữ dùng và ngày mang tính cấp bách

• Khủng hoảng ? [Webster’s Dict.]

– Điểm ngoặt tiến trình gì; thời điểm, giai đoạn biến cố định hay chủ chốt

– Điểm ngoặt trình diễn biến bệnh trở nên rõ ràng bệnh nhân sống hay chết

Khủng hoảng phần mềm gì? (tiếp)

Là sự day dứt kinh niên (kéo dài theo thời gian

thường tái diễn, liên tục không kết thúc) gặp phải phát triển phần mềm máy tính,

• Phải làm với việc giảm chất lượng lỗi

tiềm tàng có phần mềm ?

• Phải xử lý bảo dưỡng phần mềm có ? • Phải giải thiếu kỹ thuật viên phần

mềm?

• Phải chế tác phần mềm có yêu cầu phát triển

theo qui cách xuất ?

Một số yếu tố

• Phần mềm lớn 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ì tăng chi phí cho

Backlog lớn

• Nhân lực chưa đáp ứng nhu cầu phần

mềm

• Những phiền hà phần mềm gây

Những dự án lớn NASA

(National Aeronautics and Space Administration) Tên dự n

Thời ®iĨm ph¸ t triĨn

Tỉng sè b- í c (triƯu)

GEMINI Gi÷a 1960 6

APPOLO

(1 Bill $) Đ ầu 1970 13

SPACE

So sánh chi phí cho

Phần cứng Phần mềm % 100 80 60 40 20 - - -

- Phần cứng

Phát triển

Bảo trì

So sánh chi phí cho pha

3 3

5 7

8 7

67

X c định yê u cầu 3% Đ ặc tả 3%

ThiÕt kÕ 5% LËp tr×nh 7%

Backlog tại Nhật Bản năm 1985

15.5

24.7 18.4

9.4

D- í i th¸ ng 15.5%

6 thá ng đến nă m 24.7%

Từ đến nă m 32.5%

Từ đến nă m 18.4%

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 người dùng (khách hàng), sau bàn giao sản phẩm dễ phát sinh

những trục trặc (troubles)

Những vấn đề sản xuất phần mềm (tiếp)

(3) Nếu khơng có Phương pháp luận thiết kế nhất quán mà thiết kế theo cách riêng (của cơng ty, nhóm), dẫn đến suy giảm chất lượng phần mềm (do phụ thuộc nhiều vào người)

Những vấn đề sản xuất phần mềm (tiếp)

(5) Nếu khơng kiểm thử tính đắn phần mềm giai đoạn mà kiểm giai đoạn cuối phát lỗi, thường bàn giao sản phẩm khơng hạn

(6) Nếu coi trọng việc lập trình khâu thiết kế 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

Những vấn đề sản xuất phần mềm (tiếp)

(8) Phần lớn quy trình phát triển phần mềm có nhiều thao tác người thực hiện, vậy suất lao động thường bị giảm

(9) Không chứng minh tính đắn

phần mềm, độ tin cậy phần mềm giảm

Những vấn đề sản xuất phần mềm (tiếp)

(11) Khi đầu tư nhân lực lớn vào bảo trì sẽ làm giảm hiệu suất lao động nhân viên

Những vấn đề sản xuất phần mềm (tiếp)

(13) Quản lý dự án lỏng lẻo kéo theo quản lý lịch trình khơng rõ ràng

(14) Khơng có tiêu chuẩn để ước lượng nhân lực dự toán làm kéo dài thời hạn vượt kinh phí dự án

Chương

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

(Software Engineering)

3.1 Lịch sử tiến triển Công nghệ học phần mềm

3.2 Sự tiến triển 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 phần mềm

3.1 Lịch sử tiến triển CNHPM

• Nửa đầu 1960: quan tâm đến phần

mềm, chủ yếu tập trung nâng cao tính năng độ tin cậy phần cứng

• Giữa năm 1960: Phát triển hệ

điều hành phần mềm lớn (IBM

Lịch sử tiến triển CNHPM (tiếp)

• Năm 1968: Tại Tây Đức, Hội nghị khoa học

của NATO đưa từ “Software

Engineering” Bắt đầu bàn luận khủng khoảng phần mềm xu hướng hình thành CNHPM chuyên mơn riêng

• Nửa cuối 1960: IBM đưa sách phân

biệt giá phần cứng phần mềm Từ đó, ý thức phần mềm ngày cao Bắt

Lịch sử tiến triển CNHPM (tiếp)

• Nửa đầu năm 1970: Nhằm nâng cao

chất lượng phần mềm, khơng có nghiên cứu lập trình, kiểm thử, mà có

nghiên cứu đảm bảo tính tin cậy 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 năm 1970: Hội nghị quốc tế đầu

Lịch sử tiến triển CNHPM (tiếp)

• Nửa sau năm 1970: Quan tâm đến

pha quy trình phát triển phần mềm,

nhưng tập trung pha đầu ICSE tổ chức lần 2, vào 1976, 1978 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

Lịch sử tiến triển CNHPM (tiếp)

• Nửa đầu năm 1980: Trình độ học vấn

và ứng dụng CNHPM nâng cao, công nghệ chuyển vào thực tế Xuất sản phẩm phần mềm công cụ khác làm tăng suất sản xuất phần mềm đáng kể

– ICSE tổ chức lần năm 1981 1982 với

1000 người tham dự năm

– Nhật Bản sang “Kế hoạch phát triển kỹ thuật

Lịch sử tiến triển CNHPM (tiếp)

• Nửa cuối 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 suất, độ tin cậy

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)

Hiện

• Cơng nghiệp hóa sản xuất phần mềm

cách đưa kỹ thuật công nghệ học

(Engineering techniques) thành sở khoa học của CNHPM

• Thể chế hóa lý luận sản xuất phần mềm

và ứng dụng phương pháp luận cách quán

3.2 Sự tiến triển phương

pháp thiết kế phần mềm

• Phương pháp luận CNHPM: bắt

đầu từ 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ơ

Sơ khởi: nửa đầu 1970

• Khái niệm tính mơđun, cụ thể hóa

từng bước phương pháp luận thiết kế

• N Wirth: Chi tiết hóa giai đoạn

Trưởng thành: nửa cuối 1970

• Phương pháp luận quy trình thiết kế phần

mềm với phương pháp phân chia môđun thiết kế 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) J.D Warnier (1974)

Phát triển: nửa đầu 1980

• Triển khai cơng cụ hỗ trợ phát triển phần

mềm dựa phương pháp kỹ thuật đưa 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)

Biến đổi: nửa cuối 1980 đến • Đưa mơi trường phát triển phần

mềm Triển khai kết hợp CNHPM và CNH Tri thức (Knowledge Engineering)

• Triển khai mơi trường bậc cao phát

Hình thái sản xuất Phần mềm

Đưa kỹ thuật, phương pháp luận ứng dụng thực tế vào quy trình

Cải biên, biến đổi vào sản phẩm cơng cụ phần mềm (máy tính hóa phần)

Tổng hợp, hệ thống hóa cho loại công cụ

3.3 Định nghĩa Cơng nghệ học phần mềm

• Bauer [1969]: CNHPM việc thiết lập sử dụng nguyên tắc công nghệ học đắn dùng để thu phần mềm cách kinh tế vừa tin cậy vừa làm việc hiệu máy thực

• Parnas [1987]: CNHPM việc xây dựng phần mềm nhiều phiên nhiều người

• Ghezzi [1991]: CNHPM lĩnh vực khoa học máy tính, liên quan đến xây dựng hệ

Định nghĩa CNHPM (tiếp)

• IEEE [1993]: CNHPM

(1) việc áp dụng phương pháp tiếp cận có hệ thống, lượng hóa

phát triển, vận hành bảo trì phần mềm; (2) nghiên cứu phương pháp tiếp cận

được dùng (1)

Định nghĩa CNHPM (tiếp)

• Sommerville [1995]: CNHPM lĩnh vực liên quan đến lý thuyết, phương pháp công cụ dùng cho phát triển phần mềm

• K Kawamura [1995]: CNHPM lĩnh vực học vấn kỹ thuật, phương pháp luận công

Định nghĩa CNHPM (tiếp)

Công nghệ học phần mềm lĩnh vực khoa học phương pháp luận, kỹ thuật

cơng cụ tích hợp quy trình sản xuất vận hành phần mềm nhằm tạo phần mềm với 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

Công nghệ học CNHPM ? (1) Như ngành công nghệ học khác, CNHPM

cũng lấy phương pháp khoa học làm sở

(2) Các kỹ thuật thiết kế, chế tạo, kiểm thử bảo trì phần mềm hệ thống hóa hóa thành

phương pháp luận hình thành nên CNHPM (3) Tồn quy trình quản lý phát triển phần mềm

Công nghệ học CNHPM ? (tiếp)

(4) Trong vịng đời phần mềm khơng có chế tạo mà bao gồm thiết kế, vận hành bảo dưỡng (tính quan trọng thiết kế bảo dưỡng)

(5) Trong khái niệm phần mềm, khơng có chương trình mà tư liệu phần mềm

3.4 Vòng đời phần mềm (Software life-cycle)

• Vịng đời phần mềm thời kỳ tính từ

phần mềm sinh (tạo) chết đi (từ lúc hình thành đáp ứng yêu cầu, vận

hành, bảo dưỡng loại bỏ không đâu dùng)

• Quy trình phần mềm (vịng đời phần mềm)

Mơ hình vịng đời phần mềm Boehm

Xác định yêu cầu hệ thống

Kiểm chứng

Xác định yêu cầu phần mềm

Kiểm chứng

Thiết kế Kiểm chứng

Thiết kế chi tiết Kiểm chứng

Lập trình Gỡ lỗi

Suy nghĩ vòng đời phần mềm

(1) Pha xác định u cầu 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ĩ xuống (top-down) trừu tượng hóa, chi tiết hóa

Suy nghĩ vòng đời phần mềm

(4) Trước chuyển sang pha phải đảm bảo pha kiểm thử khơng cịn lỗi

(5) Cần có chế kiểm tra chất lượng, xét duyệt các pha nhằm đảm bảo không gây lỗi cho pha

sau

Suy nghĩ vòng đời phần mềm

(7) Cần chuẩn hóa mẫu biểu, cách ghi chép tạo tư liệu cho 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 việc xử lý quay vòng trở lại pha vòng đời phần

Các phương pháp luận kỹ thuật cho pha

Tªn pha Néi dung nghiƯp vơ Ph- ¬ng ph¸ p, kü thuËt

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

Ph©n tÝch cÊu tróc hãa

ThiÕt kÕ hƯ thèng

Thiết kế phần mềm

Thiết kế cấu trúc phần mềm

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

Thiết kế ch- ơng trình

L thit kế chi tiết: Thiết kế cấu trúc bê n phần mềm (đơn vị ch- ơng trình mơđun)

Lập trình cấu trúc Ph- ơng phá p Jackson Ph- ơng phá p

Warnier

Lập trình MÃ hóa ngôn ngữ lập trình MÃ hóa cấu trúc hóa Đ ảm bảo

chất l- ợ ng

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

3.5 Quy trình phát triển phần mềm

Common process framework - Khung quy trình chung

Framework activities - Hoạt động khung Task sets - Tập tác vụ

Tasks - Tác vụ

Milestones, deliverables

3.5.1 Capability Maturity Model (CMM) by SEI: Mơ hình thuần thục khả

• 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

CMM (cont.)

• Level 4: Managed (Quản trị) Both SW process and products are quantitatively understood

and controlled using detailed measures

• Level 5: Optimizing (Tối ưu) Continuous process improvement is enabled by

quantitative feedback from the process and

from testing innovative ideas and technologies

18 KPAs of CMM

LEVEL 2: Repeatable SW configuration management SW quality assurance

3 SW subcontract management

4 SW project tracking and oversight

5 SW project planning

6 Requirements management

7 Peer reviews Intergroup coordination SW product engineering 10 IntegratedSW management 11 Training program 12 Organization

process definition 13 Organization process focus

LEVEL 3: Defined

14 SW quality Management 15 Quantitative process management

LEVEL 4: Managed

3.5.2 Mơ hình tuyến tính

Phân tích Thiết kế Lập trình Kiểm thử Cơng nghệ học

Hệ thống / Thông tin

Mơ hình tuyến tính

• Cơng nghệ học Hệ thống / Thơng tin mơ hình

hóa (System / Information engineering and

modeling): thiết lập yêu cầu, ánh xạ số tập

con yêu cầu sang phần mềm trình tương tác phần cứng, người CSDL

• Phân tích u cầu (Requirements analysis): hiểu

lĩnh vực thông tin, chức năng, hành vi, tính và giao diện phần mềm phát triển Cần

Mô hình tuyến tính

• Thiết kế (Design): q trình nhiều bước với

thuộc tính khác chương trình: cấu trúc liệu, kiến trúc phần mềm, biểu diễn giao

diện chi tiết thủ tục (thuật toán) Cần tư liệu hóa và phần quan trọng cấu hình phần mềm

• Tạo mã / lập trình (Code generation /

programming): Chuyển thiết kế thành chương trình

Mơ hình tuyến tính

• Kiểm thử (Testing): Kiểm tra chương trình

và mơđun lơgic bên chức bên ngồi, nhằm phát lỗi đảm bảo với đầu vào xác định cho kết mong muốn

• Hỗ trợ / Bảo trì (Support / Maintenance): Đáp

Điểm yếu Mơ hình tuyến tính

• Thực tế dự án tn theo dịng tuần

tự mơ hình, mà thường có lặp lại (như mơ hình Boehm)

• Khách hàng tuyên bố rõ ràng

xong hết yêu cầu

• Khách hàng phải có lịng kiên nhẫn chờ đợi

3.5.3 Mơ hình chế thử (Prototyping model)

Nghe Khách trình bày

Tạo / sửa mẫu

Mơ hình chế thử: Khi ?

• Khi rõ mục đích chung chung phần

mềm, chưa rõ chi tiết đầu vào hay xử lý hoặc chưa rõ yêu cầu đầu

• Dùng “Hệ sơ khai” để thu thập yêu cầu

người dùng qua thiết kế nhanh

• Các giải thuật, kỹ thuật dùng làm mẫu có

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 chu trình phát triển ngắn (60-90 ngày)

• Xây dựng dựa hướng thành phần

(Component-based construction) với khả tái sử dụng (reuse)

• Gồm số nhóm (teams), nhóm làm RAD theo

RAD: Business modeling

Luồng thơng tin mơ hình hóa để trả lời câu hỏi:

– Thông tin điều khiển xử lý nghiệp vụ ?

– Thơng tin sinh ra?

– Ai sinh ?

– Thông tin đến đâu ?

RAD: Data and Process modeling

• Data modeling: đối tượng liệu cần để hỗ trợ nghiệp vụ (business) Định nghĩa

thuộc tính đối tượng xác lập quan hệ đối tượng

RAD: Appl Generation and Testing

• Application Generation: Dùng kỹ thuật hệ để tạo phần mềm từ thành phần có

sẵn tạo thành phần tái dụng lại sau Dùng công cụ tự động để xây dựng phần mềm

• Testing and Turnover: Kiểm thử thành

RAD: Hạn chế ?

• Cần nguồn nhân lực dồi để tạo nhóm cho

các chức

• u cầu hai bên giao kèo thời gian ngắn

phải có phần mềm hồn chỉnh, thiếu trách nhiệm của bên dễ làm dự án đổ vỡ

• RAD khơng phải tốt cho ứng dụng,

3.5.5 Các mơ hình tiến hóa:

gia tăng, xoắn ốc, xoắn WINWIN,

• Phần lớn hệ phần mềm phức tạp tiến hóa

theo thời gian: môi trường thay đổi, yêu cầu phát sinh thêm, hồn thiện thêm chức năng, tính

• 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 phiên (versions) ngày hoàn thiện hơn, phức tạp

• Các mơ hình: incremental, spiral, WINWIN

Mơ hình gia tăng

(The incremental model)

• Kết hợp mơ hình ý tưởng lặp

lại chế mẫu

• Sản phẩm lõi với yêu cầu

nhất hệ thống phát triển

• Các chức với yêu cầu khác

được phát triển thêm sau (gia tăng)

Mơ hình gia tăng

Ph©n tÝch ThiÕt kÕ LËp tr×nh KiĨm thư System/info

Engineering

Phân tích Thiết kế Lập trình Kiểm thử

Phân tích Thiết kế Lập trình Kiểm thử

Phân tích Thiết kế Lập trình Kiểm thử

Gia tăng

Gia tăng

Gia tăng

Gia tăng

Xuất xưởng Xuất xưởng

Xuất xưởng

Mô hình xoắn ốc (spiral)

Giao tiếp khách hàng

Lập kế hoạch

Phân tích rủi ro

Kỹ nghệ

Xây dựng & Khách hàng

Mơ hình xoắn ốc (tiếp)

• Giao tiếp khách hàng: người phát triển

khách hàng để tìm hiểu yêu cầu, ý kiến

• Lập kế hoạch: Xác lập tài nguyên, thời hạn

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 hay số biểu diễn

Mơ hình xoắn ốc (tiếp)

• Xây dựng xuất xưởng: xây dựng, kiểm thử,

cài đặt cung cấp hỗ trợ người dùng (tư liệu, huấn luyện, )

• Đánh giá khách hàng: Nhận phản hồi

Mơ hình xoắn ốc: Mạnh yếu?

• Tốt cho hệ phần mềm quy mô lớn

• Dễ kiểm sốt mạo hiểm mức tiến

hóa

• Khó thuyết phục khách hàng phương

pháp tiến hóa xoắn ốc kiểm sốt được

Mơ hình xoắn ốc WINWIN

• Nhằm thỏa hiệp người phát triển

khách hàng, hai “Thắng” (win-win)

– Khách có phần mềm thỏa mãn u cầu – Người phát triển có kinh phí thỏa đáng thời

gian hợp lý

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

– Xác định cổ đông (stakeholders)

Mơ hình xoắn ốc WINWIN

1 Xác định mức tiếp cổ đông

2 Xác định điều kiện thắng cổ đơng

3a Hịa hợp điều kiện thắng 3b Thiết lập mục tiêu mức tiếp ràng buộc, dự kiến

4 Đánh giá tiến trình dự kiến sản phẩm, giải rủi ro

5 Xác định mức tiếp Xét duyệt đánh giá

Mơ hình phát triển đồng thời

(The concurrent development model)

• Xác định mạng lưới hoạt động đồng thời

(Network of concurrent activities)

• Các kiện (events) xuất theo điều kiện vận

động trạng thái hoạt động

• Dùng cho loại ứng dụng cho hình ảnh

chính xác trạng thái trạng dự án

• Thường dùng phát triển ứng dụng

3.5.6 Mơ hình theo thành phần (Component-based model)

• Gắn với cơng nghệ hướng đối tượng

(Object-oriented technologies) qua việc tạo lớp (classes) có chứa liệu giải thuật xử lý 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 thành phần qua Thư

Mơ hình theo thành phần

Giao tiếp khách hàng

Lập kế hoạch

Phân tích rủi ro

Kỹ nghệ

Xây dựng & Khách hàng

Xác định thành phần

ứng viên

Tìm thành phần

từ thư viện Lấy thành phần

nếu có Xây dựng

Đặt thành phần vào thư viện Xây dựng bước lặp thứ n

3.5.7 Mơ hình hình thức (Formal model)

• Cịn gọi CNHPM phịng (Cleanroom SE)

• Tập hợp cơng cụ nhằm đặc tả tố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 sửa lỗi

khó

• Thường dùng phát triển SW cần độ an

Mơ hình hình thức: Điểm yếu ?

• Cần nhiều thời gian công sức để phát

triển

• Phí đào tạo cao người có

bản cho áp dụng mơ hình hình thức

• Khó sử dụng rộng rãi cần kiến thức

3.5.8 Các kỹ thuật hệ

(Fourth generation techniques)

• Tập hợp cơng cụ cho phép xác định đặc

tính phần mềm mức cao, sau sinh tự động mã nguồn dựa theo đặc tả

• Các cơng cụ 4GT điển hình: ngơn ngữ phi

thủ tục cho truy vấn CSDL; tạo báo cáo; xử lý dữ liệu; tương tác hình; tạo mã

4GT: How ?

• Từ thu thập yêu cầu sản phẩm: đối thoại

giữa khách người phát triển quan trọng

• Khơng nên bỏ qua khâu thiết kế 4GT áp dụng

để triển khai thiết kế qua 4GL

• Mạnh: giảm thời gian phát triển tăng suất • Yếu: 4GT khó dùng ngơn ngữ lập trình, mã

khó tối ưu khó bảo trì cho hệ thống lớn ⇒ cần kỹ kỹ sư phần mềm

3.5.9 Sản phẩm quy trình (Product and process)

• Quy trình yếu sản phẩm khó mà tốt,

song không nên coi trọng mức vào quy trình hoặc mức vào sản phẩm

• Sản phẩm quy trình cần coi

Bài tập Phần I Đồ án I

• Xem lại khái niệm, mơ hình phần mềm

CNHPM

• Đồ án mơn học I (cho 13 nhóm, nạp báo cáo, tư

liệu tìm Web thư viện):

– Tìm hiểu viết báo cáo, trình bày mơ hình

phát triển phần mềm (10 mơ hình / 10 nhóm)

– Chuẩn ISO 9001 cho SE

– Chuẩn CMM (www.sei.com)

Phần II

Phương pháp Quản lý Dự án CNTT

Chương

Quản lý dự án CNTT

Nội dung trình bày

 Tổng quan

 Lập kế hoạch quản lý  Tổ chức dự án

 Quản lý rủi ro  Phát triển nhóm

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

 Lập kế hoạch làm việc chi tiết  Kiểm soát lập báo cáo dự án

I Tổng quan

Mục tiêu

Để hiểu

 Khái niệm dự án quản lý dự án

Các định nghĩa quản lý dự án

Một dự án:

♦là riêng biệt, độc lập

♦có điểm bắt đầu điểm kết thúc

♦có sản phẩm cụ thể cuối

Tại dự án lại thất bại?

điều khiến dự án thành công?

Quản lý dự án để đưa sản phẩm cuối cùng:

• đúng hạn

• phạm vi ngân sách hay nguồn tài cho

phép

• phù hợp theo đặc tả

• với mức độ chất lượng để phục vụ nhu cầu

Định nghĩa dự án bị thất bại

Một dự án mà:

 Không đạt mục tiêu dự án, và/hoặc

 Bị vượt q ngân sách 30%

Khơng quen thuộc với phạm vi phức tạp dự án: 17%

thiếu thông tin: 21%

quản lý dự án lý khác: 12%

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

Do nhà cung cấp phần cứng/phần mềm Nhân viên kinh doanh cao cấp nhóm làm việc khơng hiệu Quản lý dự án tồi Công nghệ tổ chức Ước tính lập kế hoạch tồi Các mục tiêu dự án không nêu đầy đủ

0 10 20 30 40 50 60 70 80 90

Để tránh thất bại Cải tổ việc quản lý

dự án Nghiên cứu khả thi Tăng số thành viên tham gia Tăng phương sách từ bên ngồi Khơng phải lý

Các hoạt động dự án

Nguồn

Các đầu vào khác

các yêu cầu Các kết bàn giao

của dự án

Các đầu khác

Quản lý Dự án

Những yêu cầu người quản lý

Các thuộc tính đặc trưng dự án IT

 Các kết bàn giao hữu hình quen thuộc so với loại dự án khác

 Phạm vi khó kiểm sốt

 Đội dự án thường có kỹ năng, kinh nghiệm, thái

độ kỳ vọng trái ngược

 Dự án bị căng thẳng để đạt mục tiêu

kinh doanh

 Dự án kết nối với thay đổi quan

trọng tổ chức

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

quản lý ngời thực hợp đồng phụ quản lý cán dự án

quản lý thay đối tổ chức

quản lý rủi ro Quản l ý chất lợng

quản lý vấn đề kiểm soát thay di

Định nghĩa dự án

Lập Kế hoạch dự án

Quản lý kiĨm so¸t dù ¸n

10 quy tắc vàng

 Quản lý dự án thành cơng vấn đề người

♦ nhưng không quên quản trị

 Khám phá nguồn hỗ trợ chống đỡ

 Sự diện dối trá - xem xét lịch trình ẩn đằng sau

 Phải hiểu người khác có cách nhìn khác

nhau

♦ hãy đặt vào địa vị họ

 Thiết lập kế hoạch bạn cho chỉnh sửa dễ dàng  Đối mặt với kiện có từ trước

 Sử dụng quản trị để hỗ trợ cho mục đích dự án

 Thời gian mục tiêu nhiệm vụ không giống nêu

trong kế hoạch

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

Các mục tiêu

Sau kết thúc phần bạn sẽ:

 Hiểu cần thiết việc lập kế hoạch

các bước việc lập kế hoạch quản lý

 Có thể lập kế hoạch quản lý toàn diện một mức độ chi tiết hợp lý dự án chính bước mở đầu dự án

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

 Xác định ranh giới dự án

♦ đội lập kế hoạch, văn bản/thơng tin có

 Xây dựng lựa chọn tiếp cận dự án

♦ chiến lược thực phương pháp luận tổ chức dự án

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

 Xây dựng sở hạ tầng nguồn

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

 Xây dựng sở hạ tầng dự án

♦ quản lý cấu hình, chất lượng, rủi ro, kiện, thay đổi, kiểm soát dự án, lập báo cáo, lập kế hoạch

Các vai trò trách nhiệm dự án

Ban điều hành Chiến lược kinh doanh Không Không

Ban đạo điều hành dự án phê chuẩn từ lúc bắt đầu dự án Nhà tài trợ d/a sẵn sàng đầu vào phạm vi, từ lúc bắt đầu d/a

hỗ trợ dự án mục tiêu, lợi ích

Giám đốc dự án quản lý chiến xem xét từ lúc bắt đầu d/a

dự án phê chuẩn

Quản lý dự án quản lý hoạt động chịu trách nhiệm Trong thời gian dự án kết thực dự án Nhóm trưởng dự án chịu trách nhiệm hỗ trợ người suốt thời gian

về nhiệm vụ dự án quản lý dự án lập kế hoạch quản lý

Vai trò Trách nhiệm

Vai trò viẹc lập kế

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

Các lợi ích lập kế hoạch quản lý

Khởi đầu sai lệch

Không đáp ứng đợc mong đợi nhà tài trợ và/hoặc mục tiêu

Bị nhầm ln

Thụng tin nghốo nn

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

Gõy dng lũng tin đối tác Thiết lập hớng làm việc chung Bao quát đợc thách thức

Më c¸c kênh thông tin liên lạc

Các mục tiêu Đội dự án

Giỏ tr mục tiêu rõ ràng

 Thiết lập mong đợi nhà tài trợ

dự án nhà đầu tư

 Đưa điểm mục tiêu để hướng dẫn

đội dự án

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

 Xem xét lại văn có

 Lập danh sách văn bản/ thông tin chưa đầy đủ

hay thiếu

 Tiến hành vấn và/hoặc hội thảo để thu thập

thông tin cịn thiếu

 Phân loại thơng tin cụ thể liên quan đến

cam kết, lịch trình kết bàn giao

 Tiếp tục kết hợp chặt chẽ chi tiết vào kế

hoạch quản lý

 “Báo cáo phạm vi dự án” xây dựng

 Các lợi ích dự án lập thành văn bản rõ ràng

 Xác định kết tiêu thức để hoàn thành dự án

 Xác định rõ hạn chế, giả thuyết, điểm

Các tiêu thức 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 bán hàng

 khơng có từ viết tắt

Ngắn gọn

 25 từ

 nêu “là gì” “như nào”

Đầy đủ

 Trình bày phạm vi, lịch trình, nguồn

PM

đội chủ chốt

đội mở rộng

văn phòng dự án

Nhà tài trợ dự án

ban điều hành dự án

 Kết bàn giao đáp ứng tiêu chuẩn

 Tối thiểu hoá rủi ro dự án

 Kế hoạch làm việc xây dựng phù hợp với mẫu

 Tiến trình đo lường, ghi chép báo cáo

 Các trở ngại xác định

 Theo dõi & xem xét dữ liệu mục tiêu

 Rà xét kết bàn giao

 Báo cáo phân tích tiến trình

 Tái định hướng dự án cần thiết

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

 Các sách

 Các thủ tục hành  Các tiêu chuẩn

Ban chỉ đạo nhà tài trợ phải phê chuẩn:

 Phạm vi dự án

 Phương pháp luận sử dụng

 Thành phần đội dự án

 Ước tính kỹ lưỡng thời gian chi phí

Các yếu tố thành công

Một kế hoạch quản lý hiệu

 Mô tả tiêu thức thành công dự án;

 Phác thảo khung thời gian, ngân sách, kết 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 khung thời gian tổng quan việc thực thi dự án;

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

 Điểm chủ yếu để hiểu dự án

♦ lập cấu trúc hay khuôn khổ cho tất

cácvăn quản lý dự án

 Nền tảng vững cho quản lý dự án

♦ Truyền thông

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

III Tổ chức dự án

Các mục tiêu tổ chức dự án

Vào cuối phần này, người tham dự khoá học có thể:

 Hiểu tầm quan trọng tổ chức tốt  Thiết lập cấu đội dự án hiệu

 Phân định vai trò trách nhiệm

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

 Xác định “những người có ảnh hưởng” dự án

 Xác định lĩnh vực chủ yếu có lực cản

 Tác động qua lại yêu cầu dự án trước thành lập uỷ ban hay hội đồng

 Danh sách thành viên tiềm ban điều hành dự án

 Biểu đồ tổ chức dự án: - cấu trúc quản lý dự án - cấu trúc đội dự án

 Vai trò trách nhiệm dự án

 Mô tả công việc dự án

Quy trình tổ chức dự án

Xác định vị trí

dự án tổ chức

Thiết kế tổ chức dự án

Lập thành văn bản vai trò trách nhiệm

dự án

Xây dựng mô tả công việc quyền

lợi vị trí

Lựa chọn đội dự án Step

Step

Ví dụ cấu trúc Quản lý dự án Ban điều hành dự án

Chủ tịch = nhà tài trợ dự án

Quản lý đơn vị nghiệp vụ Quản lý bảo đảm

chất lượng Quản lý dự án

nhóm trưởng nhóm trưởng quản lý nhóm nhóm trưởng

Những điểm chính:

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

 Cơ cấu người vô quan trọng đối

với thành công dự án

♦ giám đốc dự án điều hành nhóm quản lý ♦ các mối quan hệ cần phải thiết lập

 Vai trị kiểm sốt dự án phải ln có nhiệm vụ kiểm sốt quản trị

♦ khơng cần thiết phải có cán làm việc full time

Vai trò trách nhiệm dự án

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

giám đốc dự án đại diện cho nhà tài trợ dự án

ban đạo giám sát hoạt động dự án, hỗ trợ việc lập phương hướng để đưa định nhóm nghiệp vụ thừa nhận kết bàn giao chủ yếu

nghiệp vụ

quản lý dự án điều phối dự án tổng thể, quản lý giám sát (có hỗ trợ hành từ văn phịng dự án) nhóm trưởng hàng ngày quản lý kiêm soát tiến triển theo

kế hoạch làm việc chi tiết

Các yêu cầu mô tả

 Ngắn gọn súc tích  Xác định rõ:

♦ Các mục đích mục tiêu

♦ Những trách nhiệm ♦ Số thành viên

Văn phịng dự án gì?

Là trung tâm của:

 Họp

 Điều phối, kết hợp

 Theo dõi

Nhiệm vụ trách nhiệm văn phòng dự án

ph©n tÝch xu híng

sơ đồ tổ chức

kiểm soát thay đổi lập bỏo cỏo

về thực trạng lập bảng

biểu

đa

giải pháp sử dụng

các nguồn

duy trì kế hoạch

ngân sach dù ¸n lËp b¸o c¸o

theo thêi gian ®a

các kết khơng cần thẩm định

gi¸m s¸t thêi gian híng dÉn lËp kÕ ho¹ch

theo dõi lịch trình

Tổ chức dự án - Các điểm học

 Nhà tài trợ có trách nhiệm cao 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ý cán kỹ thuật cán chức năng

 Hồn thành cơng việc dự án với nguồn lực

 Dịng thơng tin liên lạc hiệu

 Tỉ lệ cán so với người quản lý nhỏ

 Tối giản mức báo cáo, loại trừ yêu cầu không

cần thiết

IV Quản lý rủi ro

Những mục tiêu phần

 Hiểu cần thiết quản lý rủi ro

trong suốt trình thực dự án

 Có thể thực việc phân tích đánh giá rủi ro dự án

Định nghĩa rủi ro

Những kiện làm phá vỡ dự án

Những điều không chắn, khoản nợ hay

những điểm yếu làm cho dự án không theo đúng kế hoạch định

Có thể quản lý

Các lý cần có quản lý rủi ro

 Tất dự án phụ thuộc vào rủi ro  Tiến trình khơng theo kế hoạch

trong một số giai đoạn dự án

Định nghĩa quản lý rủi ro

 Giảm thiểu ảnh hưởng cố không

biết trước cho dự án

 Nâng cao xác suất thực thành công dự án

 Tạo ý thức kiểm soát

 được giải pháp hiệu kịp thời

Khi cần quản lý rủi ro  Lập kế hoạch quản lý

 Khi trách nhiệm dự án sẵn sàng thực thi

 Khi khôi phục dự án bỏ dở

 Trong suốt trình rà xét dự án

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

Xác định mức rủi ro ban đầu

của dự án lập thành văn

rủi ro cụ

thể tiến hành phân tích ảnh hưởng

rủi ro triển khai kế xây dựng hoạch quản lý

rủi ro

giám sát

Xác định Phân tích Quản lý Giám sát

bước

bước

bước

Hoạt động ngăn ngừa (ví dụ)

 Đưa đào tạo bổ sung cho lập trình viên (để

giảm rủi ro tiềm năng)

 Thuê hợp đồng với lập trình viên có nhiều kinh nghiệm (loại bỏ rủi ro tiềm năng)

Đội dự án bị chậm so với lịch trình

giai đoạn xây dựng phần mềm nhà lập trình đang giai đoạn khó mã chương

trình dự đoán Xác suất khoảng 30 % nhân viên đáp ứng kiện

Hành động dự phòng

Phải:

 Dựa thừa nhận từ thực

tiễn (ví dụ: nguồn sẵn có)

 Các thành viên nhóm phải hiểu được (và uỷ ban điều hành)

 Phải kiểm tra tính khả thi

Các điểm học

Chương trình quản lý rủi ro hiệu

 Tập trung vào việc phòng ngừa chữa trị

 Bao gồm đánh giá rủi ro theo thời kỳ suốt vòng đời của dự án

 Kết hợp chặt chẽ quy trình liên tục xác định rủi ro,

phân tích, quản lý rà xét

 Nhận biết giá trị quyền hạn

không giới hạn kết thúc khơng xác!

V Phát triển nhóm

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

 Xây dựng hiểu biết bạn

các đặc tính nhóm làm việc hiệu

 Xác định phương pháp để

Nhóm hiệu

 Các mục đích thống

 Nhóm tin tưởng vào vai trò mục tiêu

 Chấp thuận mục tiêu dự án chất

lượng dự án

 Truyền thông đối lưu hiệu

 Các ý tưởng trao đổi triển khai

 Đưa giải pháp hiệu

 Mối quan hệ hợp tác hỗ trợ thành

thành lập xung kích Quy chuẩn thực

xây dựng nhóm

lịch trình

của thành viên hợp tác cam kết

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

Xây dựng nhóm - điểm học

 Mục tiêu rõ ràng

 Trách nhiệm rõ ràng

 Thông tin liên lạc hiệu

 Phản hồi có tính xây dựng  Lãnh đạo linh hoạt

 Cán đủ khả

 Xác định với nhóm

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

Hai Định nghĩa Chất lượng

Thích hợp với mục đích

Thoả mãn

nhu cầu

mục đích

thực phương pháp

Các khái niệm chất lượng chủ chốt

 Đạt chất lượng phải đựoc lên kế

hoạch - không tuỳ tiện

 Đạt chất lượng xuất phát từ bảo

đảm chất lượng kiểm soát chất lượng

 Đạt chất lượng phụ thuộc vào hỗ

Quản lý chất lượng 1.Lập kế

haọch chất lượng

2.Thiết lập khung đảm bảo chất

lượng

3 Tiến hành hoạt động kiểm soát chất lượng

4 Triển khai họat động hiệu

Những điểm chủ chốt học

 Cam kết quản lý

 Người sử dụng tham gia

 Cấu trúc phương pháp tiếp cận

 Các yêu cầu chất lượng đo lường

 Thẩm định phương pháp, kiểm sốt, quy trình

và sản phẩm dự án

 Thông tin liên lạc

một kế hoạch có chất lượng tốt mô tả việc làm

VII Lập kế hoạch làm việc chi tiết

Các mục tiêu phần

 Giải thích mối quan hệ Kế hoạch hoạt động (một phần

của kế hoạch quản lý) Kế hoạch làm việc

 Nhìn vào yếu tố cuả kế hoạch: Tài liệu nhiệm vụ Các phụ thuộc Các nguồn lực

 Để giải thích chu kỳ lập kế hoạch làm việc

Làm thế để tạo kế hoạch làm việc

 Tách giai đoạn thành hoạt động

 Tách hoạt động thành nhiệm vụ

 Các nhiệm vụ nhỏ dễ dàng ước tính quản lý giai đoạn lớn

 Các nhiệm vụ cần:

♦ thường không nhỏ người/giờ làm việc ♦ thường không nhiều 70 người/giờ làm việc ♦ thường không sử dụng nhiều hn ngun

Giai đoạn

Møc

hoạt động hoạt động

Møc

nhiƯm vơ nhiƯm vơ nhiƯm vơ nhiƯm vơ

Møc

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

Mục tiêu nghiệp vụ

kế hoạch hoạt động

định nghĩa kế hoạch

Các hoạt động cần đạt

được kết bàn

giao mốc xác

định WBS

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

Xác định nhiệm vụ

 thiết kế để đưa kết bàn giao

(như phần hoạt động)

 trách nhiệm cá nhân

 có hạn

♦ xác định tiêu thức việc bắt đầu kết thúc

 đơn vị cơng việc quản lý  dễ hiểu

Xác định nhiệm vụ phụ thuộc

 Không bị cản trở nguồn giai đoạn

 Hỏi “Công việc cần hồn thành trước nhiệm vụ

có thể bắt đầu?”

 Hỏi “Những nhiệm vụ thực cơng

việc kết thúc?”

 Giảm tối đa chuỗi dài nhiệm vụ phụ thuộc

 Thực nhiệm vụ song song với  Xem xét khoảng cách

 Xem xét chồng chéo

 Chuyển thông tin phụ thuộc vào thành công cụ lập

Chỉ định nguồn lực cho nhiệm vụ

Các nguyên tắc

 Sử dụng hợp lý nguồn

 Kinh nghiệm & kỹ đáp ứng nhu cầu nhiệm vụ

 không bỏ qua cán thiếu kinh nghiệm

Các nguồn dự án cam kết để đạt mục tiêu dự án nguồn Quản trị viên dự án tổ chức đạo để đạt mục tiêu dự án phạm vi chi phi lịch trình cho phép

Các loại nguồn tiêu biểu bao gồm:

Nguồn lực dự án gì?

 Con người - người lựa chọn cho đội dự án Họ thể kinh nghiệm kỹ 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ó bao gồm từ

những thiết bị lớn đến máy tính cơng cụ kiểm tra đặc biệt

 Văn phòng phẩm - đồ dùng cần thiết cho dự án Nó có

thể bao gồm thứ từ giấy bút chì đến đĩa mềm đồ vật khác

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 nguồn

 Dàn xếp chỗ thừa chỗ thiếu nguồn

 Xem xét hạn chế của: ♦ nhiệm vụ phụ thuộc

♦ nguồn sẵn có

 Là quy trình lặp lại ♦ thời gian biểu 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

10 đặc điểm kế hoạch làm việc tốt

1 Chia nhỏ giai đoạn lớn phức tạp (tức kế hoạch quản lý) thành nhiều nhiệm vụ quản lý

2 Xác định phạm vi mục tiêu nhiệm vụ

3 Xác định nguồn cần để thực nhiệm vụ 4 Xác định thời gian cần sử dụng nguồn nhiệm vụ 5 Xác định thời điểm bắt đầu kết thúc nhiệm vụ 6 Bao gồm ước tính thực tế

7 Giảm tối đa thất thường công việc sử dụng nguồn 8 Kết hợp chi phí nhiệm vụ dự phòng

9 Tiêu chuẩn hố dự án để giám sát

Các nhân tố thành công Những điều học

 Một kế hoạch làm việc tốt xác định mục tiêu phạm

vi lượng cơng việc quản lý

 Nó xác định nỗ lực, nguồn lịch trình đáp ứng nhu cầu của mục tiêu

 Nó thực tế bao gồm phần dự phịng

 Nó sử dụng nguồn hiệu hợp lý

 Nó thiết lập tiêu chuẩn để kiểm tra tiến trình cơng việc

VIII Kiểm sốt lập báo cáo dự án

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

Để :

 Chứng minh cần thiết việc lập báo cáo kiểm

soát dự án hiệu giải thích lợi ích

 Để nhận biết phương pháp kỹ khác

được sử dụng cho việc lập báo kiểm soát dự án

 Đánh giá tầm quan trọng việc trình bày thơng tin

hhiện trạng hợp lý cho thính giả khác

 Đánh giá tầm quan trọng cuả chu kỳ kiểm soát dự án

Các định nghĩa

Kiểm soát dự án:

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

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

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

♦ Báo cáo khách quan thực trạng dự án

♦ Xác định cản trở hành động hiệu chỉnh ♦ Triển khai giải pháp

♦ Hiểu ảnh hưởng công việc tương lai

♦ Đưa định hợp lý dựa thông tin xác thực

 Quản trị viên dự án, trưởng nhóm thành viên nhóm

phải:

♦ Lắng nghe tin nhắn chuyển đến

Lập báo cáo hiệu thực trạng vấn đề

toàn dự án sẽ:

Trao đổi tình trạng dự án

 Tập trung vào thành tựu mục tiêu

kinh doanh, khơng phải vào quy trình dự án

 Đưa thơng tin xác tin cậy dựa kế

hoạch dự án

 Nêu bật điểm ngoại lệ so với kế hoạch

 Cung cấp thông tin kịp thời

Dự án Giai đoạn

Phạm vi

Nhiệm vụ Hoạt động

Mức WBS

1

Quan sát bên

Lập kế hoạch, theo dừi, bỏo cỏo

Các mục tiêu kinh doanh

Kết bàn giao Xác định kết bàn giao

kế hoạch hoạt động

xác định kế hoạch

Dữ liệu - đầy đủ

B¸o cáo thực trạng

Các báo cáo từ kế haọch

Báo cáo vấn đề

Xác định vấn đề

Lập báo cáo kiểm soát dự án Replan/ Rebaseline quản lý thực hành kế hoạch quản lý KH công việc

chi tiết

dữ liệu tiến trình

dữ liệu hoàn thiện

khác dữ liệu nhiệm vụ quản lý nguồn kiểm soát khác giải pháp

lập báo cáo hiện trạng

xu hướng nguồn

tài thay đổi

phiên vấn đề chất lương

phân tích hoạt động hiệu chnh

kế hoạch

công việc

chi tiết

theo dõi rà xét

các kiện

mục tiêu

rà xét KQBG

nỗ lực báo cáo phân tích trình tiến

Tái định hướng

dự án

Khuôn khổ kiểm sốt dự án

C«ng viƯc kiĨm so¸t Møc

kiĨm so¸t

B¸o c¸o

Ban điều hành

Quản trị viên dự án

Trởng nhóm

B/c Ban điều hành

B/c Quản trị viên dự án

B/c trởng nhóm

B/c thành kế hoạch quản lý

kế hoạch công việc chi tiết kế hoạch công việc chi tiết

Một chu kỳ kiểm soát dự án thống nhất:

Chu kỳ kiểm soát dự án

 Nêu rõ ràng chu kỳ kiện cho việc lập báo cáo thực trạng

 Xác định thông tin thông thường yêu cầu với 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

Chu kỳ kiểm soát dự án - yếu tố

HĐQT Uỷ ban điều

hành

Các giám đốc dự án Các nhà tài trợ kinh doanh

Chủ thực

Ai Khi

Chủ thực Quản trị viên dự án

Quản lý kinh doanh

hàng tháng: thứ sáu

2 tuần lần: thứ hai tuần lần: thứ tư

hàng tuần: thứ sáu Các giám đốc dự án

Quản trị viên dự án quản lý đơn