Các giai đoạn quản lý dự án công nghệ thông tin

CHƯƠNG 2. CÁC GIAI ĐOẠN QUẢN LÝ DỰ ÁN CNTT
I. GIAI ĐOẠN XÁC ĐỊNH YÊU CẦU
1. Mục đích
Mục đích của giai đoạn này là có được một sự hiểu
biết đầy đủ về các vấn đề, các yêu cầu của người dùng
có thể hình dung được đầy đủ về các vấn đề của dự
án, ước lượng được giá thành và thời gian thực hiện.
2. Các hoạt động chính
– Tìm hiểu thấu đáo về các vấn đề của người dùng
và những gì cần thiết để giải quyết vấn đề đó.
– Cần phải quyết định có thực hiện hay không thực
hiện dự án. Ta cần phải biết chắc rằng dự án là khả
thi và có nhiều cơ hội để thành công.
1


• Nếu dự án có thể thực hiện được, cần phân tích
đánh giá các rủi ro có thể xảy ra và chi tiết hoá tất
cả các kết quả cần đạt được, khi nào và với giá
thành bao nhiêu.
• Cũng từ giai đoạn này, ta phải bắt đầu ngay các
hoạt động về quản lý dự án, xem xét, báo cáo và tư
liệu hoá; và tiếp tục tiến hành các hoạt động đó cho
đến khi kết thúc dự án.

2


3. Các tài liệu cần phải viết
• Đề cương dự án: khởi đầu của một dự án, để đề
đạt lên cấp trên xem xét và ủng hộ cho thực hiện;

• Nghiên cứu khả thi: để chứng minh rằng dự án có
thể thực hiện được về mặt kỹ thuật với chi phí có
thể chấp nhận được so với lợi ích kinh tế mà nó sẽ
đem lại; tài liệu phải được nhà đầu tư thông qua;
• Tài liệu yêu cầu: giúp cho nhóm dự án hiểu rõ về
những yêu cầu của người dùng và trên cơ sở đó
mới có thể đề ra giải pháp cụ thể thích hợp và ước
tính giá thành của nó; (trong trường hợp cụ thể, đây
chính là tài liệu gọi thầu). Tài liệu này phải được
người dùng thông qua;
3


• Danh sách rủi ro: dự đoán trước những trở ngại để
chuẩn bị phương án đối phó;
• Kế hoạch ban đầu: vạch ra các bước chính, làm cơ
sở đầu tiên để ước lượng và lập lịch cho dự án. Kế
hoạch đưa ra phải được cả nhóm dự án thống nhất;
• Đề xuất: giải pháp cho người dùng: ước lượng ban
đầu về giá thành và thời hạn cho dự án. Đối với các
dự án bên ngoài, đây là tài liệu chính thức trình bày
những ý định của nhóm dự án nhằm cung cấp các
dịch vụ mà ngươì dùng yêu cầu (tài liệu dự thầu).
Điểm mốc cần thiết là tài liệu này được chủ dự án
chấp thuận hoặc chủ đầu tư quyết định trúng thầu.
4


4. Kết luận
Các mốc chính của giai đoạn xác định là:

- Quyết định đầu tư hay không đầu tư cho dự án.
- Hoàn thành tài liệu yêu cầu được người dùng
thông qua.
- Lên kế hoạch ban đầu với sự nhất trí của các
thành viên trong nhóm dự án.
- Tài liệu đề xuất giải pháp được chủ dự án thông
qua để thực hiện.

5


II. GIAI ĐOẠN PHÂN TÍCH
1. Mục tiêu

– Nhằm xác định chính xác hệ thống thông tin dự
định xây dựng sẽ “làm gì" cho người sử dụng, và
nó sẽ hoà nhập vào môi trường của người sử dụng
như thế nào, nói cách khác, trong giai đoạn này
phải xác định mọi yêu cầu, mọi vấn đề đặt ra mà hệ
thống thông tin phải đáp ứng.
– Mặc dù theo lý thuyết thì trong giai đoạn phân tích
chỉ cần xác định được xem hệ thống sẽ phải làm
những gì. Tuy nhiên trên thực tế, kết thúc giai đoạn
này người quản lý dự án phải hình dung ra được
hệ thống sẽ thực hiện các chức năng chính đó như
thế nào?
6


2. Các công việc phải thực hiện

2.1. Công việc chính là viết tài liệu xác định mọi
chức năng, mọi hành vi của hệ thống. Tài liệu này
được gọi là tài liệu Đặc tả chức năng (Functional
Specifications - FS).
2.2. Sau khi viết xong Đặc tả chức năng, chúng ta
đã có hiểu biết đầy đủ hơn về hệ thống thông tin
cần phải xây dựng so với giai đoạn xác định, do đó
cần xem xét lại kế hoạch dự án ban đầu. Trên cơ sở
xem lại viết Kế hoạch dự án cuối cùng (Final Project
Plan FPP).
7


2.3. Trong trường hợp dự án được thực hiện theo
phương pháp hai bước thì kết thúc giai đoạn phân
tích chính là kết thúc bước 1, ta cần đề xuất và
đánh giá thực hiện bước hai. Đề xuất này được thể
hiện qua việc viết Tài liệu đề xuất phát triển
(Development Proposal - DP).
2.4. Trong giai đoạn phân tích, ta cũng thực hiện
một phần công việc của giai đoạn thiết kế. Đó là
Thiết kế tổng thể (thiết kế mức tổng quát - Top level
design - TLD). Như vậy ở giai đoạn này chúng ta có
thể hình dung hệ thống sẽ thực hiện các chức năng
chính như thế nào.
8


3. Viết tài liệu "đặc tả chức năng”
• Đặc tả chức năng là tài liệu mô tả toàn bộ hoạt động

của hệ thống, các giao diện người sử dụng. Trong
tài liệu này cần:
– Mô tả chi tiết nhất có thể các thông tin vào,
thông tin ra, các yêu cầu về thực hiện, các thủ
tục, các quy trình....
– Giải thích các thay đổi môi trường của người sử
dụng do đưa vào hệ thống mới.
– Mô tả tất cả các sản phẩm chuyển giao bao gồm
phần cứng, phần mềm, đào tạo, các tài liệu, các
đảm bảo về bảo hành....
9


Đặc tả chức năng chính là tài liệu nói rõ "cái gì" hệ thống sẽ
làm cho người sử dụng. Tài liệu này nếu làm nghiêm túc, cẩn
thận sẽ giúp cho chúng ta:
- Hệ thống hoá và ghi nhớ được đầy đủ các vấn đề, các yêu
cầu, đặt ra đối với hệ thống, làm cơ sở pháp lý để giải quyết
và triển khai các giai đoạn sau.
- Giải quyết nhiều vấn đề phức tạp của hệ thống trước khi
thực hiện thiết kế kỹ thuật và lập trình, làm cho việc nghiên
cứu các dữ liệu, các chức năng xử lý và mối quan hệ giữa
chúng được rõ ràng mạch lạc.
- Tạo điều kiện thuận lợi để các nhóm chuyên gia khác nhau
có thể kế thừa thực hiện hoặc hoàn thiện hệ thống trong
những giai đoạn tiếp theo.
10


• Tài liệu đặc tả chức năng chỉ có thể hoàn thành sau

một quá trình khảo sát thực trạng, thu thập ý kiến từ
nhiều người, nhiều bộ phận nghiệp vụ khác nhau,
sau nhiều buổi phân tích, trao đổi ý kiến của cán bộ
chuyên môn và các chuyên gia tin học.
• Đặc tả chức năng là kết quả đúc kết từ quá trình
làm việc này và được trình bày như kết quả nhận
thức của các nhà phân tích hệ thống về mọi khía
cạnh của các vấn đề đặt ra qua các mức độ khái
quát hoá khác nhau.

11


4. Xem xét lại kế hoạch
• Làm kế hoạch là quá trình lặp. Do đó ngay sau khi
tiến hành phân tích xong, cần xem xét lại kế hoạch
dự án ban đầu. Cần nhớ rằng đã nhiều thời gian trôi
qua kể từ khi chúng ta viết kế hoạch dự án ban đầu
và rất nhiều hiểu biết đã được bổ sung trong thời
gian đó. Do đó có điều kiện để đánh giá lại cơ cầu
phân việc, các nhiệm vụ, bổ nhiệm người thực hiện,
lên lịch và thực hiện.
• Chú ý vấn đề nhân sự, các rủi ro

12


5. Kế hoạch dự án cuối cùng
• Sau khi xem xét lại dự án ban đầu cần viết kế hoạch
dự án cuối cùng. Về bố cục, kế hoạch dự án cuối

cùng giống như kế hoạch dự án ban đầu, song từng
khoản mục cần được xem xét, điều chỉnh, chi tiết
hoá, chính xác hoá. Mức đánh giá tại thời điểm này
là mức B (+/- 25%). Đồng thời trong báo cáo dự án
cuối cùng cần bổ sung thêm các phần:
– Quản lý sự thay đổi.
– Đào tạo, huấn luyện đội dự án.

13


6. Thiết kế tổng thể
• Thiết kế mức tổng thể là mô tả chung kiến trúc hệ
thống.
• Mô tả này được bắt đầu bằng việc nêu ra các thành
phần chính của phần cứng và chúng được nối với
nhau trên mạng như thế nào.
• Tiếp theo là nêu ra các thành phần chính của phần
mềm: Liệt kê các phần mềm trên các máy chủ (máy
phục vụ), trên mỗi máy khách hàng. Đối với mỗi
phần mềm cần đặt làm, phải có thiết kế riêng. Mức
tổng quát chỉ kể ra các thành phần chính của phần
mềm.
14


Thiết kế tổng thể cần chú ý các yếu tố sau:
•
•
•

•
•
•
•

Chi phí hệ thống
Thời gian cần thiết để xây dựng hệ thống.
Tính thân thiện đối với người sử dụng
Thực hiện
Kích thước hệ thống
Độ tin cậy
Khả năng thay đổi.

15


7. Kết luận
Các mốc chính của giai đoạn phân tích là:
• Đặc tả chức năng được hoàn thành, thông qua và
ký nhận.
• Nếu dự án được thực hiện theo phương án hai
bước, thì cần viết tài liệu đề xuất phát triển.
• Kế hoạch dự án ban đầu được xem xét lại và từ đó
hoàn thành kế hoạch dự án cuối cùng.
• Hoàn thành thiết kế mức tổng thể.

16


III. GIAI ĐOẠN THIẾT KẾ

1. Mục tiêu
Giai đoạn thiết kế nhằm xác định mục tiêu chính xác
hệ thống sẽ làm việc "như thế nào". Nói một cách
khác nó phải xác định các bộ phận, các chức năng
và các mối liên kết giữa chúng của hệ thống.
2. Các công việc
Viết thiết kế hệ thống thông tin được tiến hành lần
lượt theo 3 mức:
• Mức tổng thể: thiết kế mức tổng thể thường được
thực hiện ở cuối giai đoạn phân tích. Nó cho thấy
kiến trúc chung của hệ thống về cả phần cứng và
phần mềm. Sử dụng các mô hình khái niệm để minh
hoạ.
17


Mức giữa: Thiết kế ở mức giữa đơn giản là tiếp tục việc
chia nhỏ bản thiết kế ở mức tổng thể thành các thành phần
nhỏ hơn. Các thành phần của phần cứng được chi tiết đến
mức các khối. Các thành phần phần mềm được chi tiết đến
mức các chương trình trong mỗi môđun hoặc mỗi ứng
dụng. Sử dụng đến các mô hình logic để minh hoạ.
• Thiết kế Môđun: (được tiến hành trong giai đoạn thực
hiện): đây là mức (thấp nhất) chi tiết nhất, nhằm thiết kế ra
các thành phần cơ bản tạo ra phần cứng, các chương trình
con tạo thành các chương trình phần mềm ứng dụng. Mức
này thường do các chuyên gia phát triển làm trong giai
đoạn thực hiện. Các sơ đồ ở đây chi tiết đến từng dữ liệu
và thao tác.

•

18


• Với quy trình thiết kế mô tả như trên, các công việc của giai
đoạn thiết kế bao gồm:
2.1 Thiết kế hệ thống mức giữa và phối hợp với kết quả thiết
kế hệ thống mức tổng thể để viết tài liệu Đặc tả thiết kế
(Design Specification - DS)
2.2 Soạn thảo tài liệu "Kế hoạch kiểm thử để chấp nhận"
(Acceptance Test Plan - ATP). Đây là tài liệu liệt kê tất cả các
phép thử sẽ phải thực hiện để kiểm tra tất cả các chức năng
của hệ thống cho người dùng thấy trong giai đoạn chấp nhận.
• Mốc chính của giai đoạn này là tài liệu Đặc tả thiết kế được
xem xét thông qua và được chứng tỏ là không sai sót. Cũng
có thể trong giai đoạn này người sử dụng kiểm duyệt "Kế
hoạch kiểm thử để chấp nhận”.
19


3. Đặc tả thiết kế
Tài liệu đặc tả thiết kế là tài liệu mang tính chất kỹ
thuật. Nó được viết để cho các lập trình viên đọc và
hiểu để thực hiện. Những người sử dụng cũng có
thể đọc song không nhất thiết phải hiểu tất cả. Khi
viết tài liệu này cần chú ý đến các điều sau đây:
• Phải sử dụng ngôn ngữ chặt chẽ, chính xác.
Nguyên nhân lớn thứ hai gây ra sai sót trong hệ
thống phần mềm là do lập trình viên hiểu sai thiết kế

(Nguyên nhân lớn gây ra sai sót là do nhà phân tích
hiểu sai nhu cầu của người dùng).
• Sử dụng các sơ đồ, các hình vẽ, các mô hình thiết
kế chuẩn.
20


• Hãy cố gắng làm cho các ý đồ thiết kế được thể
hiện ngay trong những trang đầu tiên, sau đó sẽ giải
thích chi tiết.
• Bảo đảm tính nhất quán về ngôn ngữ trình bày, cả
về lời văn lẫn các hình vẽ. Cách tốt nhất là để một
người viết toàn bộ. Trong trường hợp cấp bách về
thời gian phải dùng một số người viết thì những
người này phải cố gắng để có văn phong chung.

21


4. Một số vấn đề trong quá trình thiết kế
a. Đội thiết kế
• Nhà quản lý dự án phải chọn những người tốt nhất vào đội
thiết kế: họ phải là những người có đầu óc tổng hợp, có thể
hình dung tổng thể sự việc. Cần tránh quan điểm cầu toàn,
hoàn thiện trong đội thiết kế. Chúng ta luôn luôn có thể tìm ra
cách tốt hơn để thực hiện dự án nếu có đủ thời gian và nguồn
lực, nhưng cần phải nhớ là chúng ta bị hạn chế về thời gian
và kinh phí. Có nhiều sự so sánh lựa chọn phải làm trong thời
gian thiết kế, do đó đội nên có một số lẻ người, hoặc ít ra
phải có đội trưởng giỏi, để dễ dàng trong việc bỏ phiếu

quyết định một vấn đề gì đó cần sự thống nhất.
• Đối với đội thiết kế cần lập kế hoạch lên các lịch họp và cố
gắng đảm bảo các cuộc họp được liên tục.

22


b. Rà soát lại bản thiết kế
• Cần tiến hành các cuộc họp để rà soát lại bản thiết
kế trên khía cạnh kỹ thuật. Cuộc họp gồm các đại
biểu của đội dự án và có thể có thêm các đại biểu
từ các nhóm khác.
• Trong khi rà soát lại cần đảm bảo rằng thiết kế:
– Đáp ứng được tất cả các đặc tả chức năng đã
đề ra.
– Được chia thành các thành phần một cách logic.
– Mọi vấn đề kỹ thuật được trình bày rõ ràng, dễ
hiểu và nằm trong giới hạn về thời gian và giá cả.
23


5. Vấn đề chấp nhận dự án
• Chấp nhận dự án là việc người sử dụng khẳng định
bằng văn bản rằng sản phẩm đã được cung cấp
đúng như thoả thuận, và nếu đó là dự án được thực
hiện dưới dạng hợp đồng thì cần tiến hành thanh
toán hợp đồng. Mặc dù chưa đến giai đoạn chấp
nhận, song giai đoạn thiết kế là thời điểm tốt nhất
để bắt đầu lập kế hoạch cho giai đoạn này.
• Chính tại giai đoạn chấp nhận, lần đầu tiên người

dùng thực sự mới được trông thấy và sử dụng sản
phẩm. Họ cần kiểm tra để xem có chấp nhận được
sản phẩm đó hay không.
24


6. Xem xét lại các ước lượng
• Tại thời điểm cuối của giai đoạn thiết kế, chúng ta
tiếp tục xem xét lại kế hoạch dự án, đặc biệt là xem
xét lại các đánh giá. Mặc dù bây giờ chúng ta chỉ
đánh giá bốn giai đoạn còn lại, song phần lập trình
trong giai đoạn thực hiện có thể là tốn kém thời gian
và công sức nhất trong toàn bộ dự án. Thiết kế cho
chúng ta biết số các môđun và ước lượng độ phức
tạp của chúng. Đồng thời bây giờ ta cũng đã biết ai
sẽ là lập trình viên và có thể đưa năng suất của họ
vào các đánh giá. Như vậy có thể dễ dàng đánh giá
chính xác hơn lượng thời gian cần thiết để lập trình.
Thống kê đã cho thấy là vào cuối giai đoạn thiết kế,
ước lượng thuộc loại lớp A (sai số +/- 10%).
25