bài giảng quản lý dự án công nghệ thông tin

1
GIAI ĐOẠN PHÂN TÍCH
ThS. Nguyễn Khắc Quốc
IT Department – Tra Vinh University
2
3.1 Mục đích
- Xác định hệ thống dự định xây dựng sẽ “làm gì"
- Hoà nhập vào môi trường của người sử dụng “như thế
nào”,
- Xác định mọi yêu cầu, mọi vấn đề đặt ra mà hệ thống
phải đáp ứng.
- Trên lý thuyết: xác định được xem hệ thống sẽ phải
làm những gì.
- Trên thực tế: 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?
3
3.2 Các công việc phải thực hiện
3.2.1. 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  là tài liệu Đặc tả chức năng (Functional
Specifications - FS).
3.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).
4
3.2 Các công việc phải thực hiện (tt)
3.2.3. 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).
3.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 không phải chúng ta chỉ xem
xét hệ thống sẽ thực hiện các chức năng như thế nào.
5
3.3 Viết tài liệu "đặ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.
- Mô tả chi tiết 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
- Đặ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.
6
3.3 Viết tài liệu "đặc tả chức năng” (tt)
Tài liệu này giúp cho chúng ta:
- Hệ thống hoá và ghi nhớ đầ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.
7
3.3 Viết tài liệu "đặc tả chức năng” (tt)
Tài liệu đặc tả chức năng chỉ có thể hoàn thành:
+ Sau 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ác bộ chuyên môn và các chuyên gia tin học.
8
3.3 Viết tài liệu "đặc tả chức năng” (tt)
- Là tài liệu kỹ thuật nhưng được viết cho những người
không am hiểu kỹ thuật đọc để làm cơ sở cho việc ký
kết hợp đồng giữa bên thực hiện dự án và người sử
dụng.
- Do đó cần:
+ Học để hiểu biết công việc và ngôn ngữ của
người sử dụng
+ Dùng các sơ đồ nhiều nhất có thể được.
+ Phải viết rất chính xác,
+ Tránh mập mờ, những câu dễ hiểu sai.
9
3.4 Dàn bài của đặc tả chức năng
1. Trang bìa, số phiên bản (do tài liệu này có thể được
viết và sửa lại một số lần nên cần đánh số phiên bản để
biết đó là tài liệu soạn lần thứ mấy).

2. Mục lục.
3. Tổng quan về hệ thống
- Mô tả chung về hệ thống, các chức năng chính, quan
hệ giữa chúng.
- Nên dùng nhiều sơ đồ, người dùng dễ hình dung các
chức năng của hệ thống và quan hệ của các chức năng.
10
3.4 Dàn bài của đặc tả chức năng (tt)
4. Các mục tiêu chính
- Liệt kê các mục tiêu của hệ thống, quan hệ mỗi mục
tiêu với các modun của hệ thống.
- Cần mô tả hệ thống mới được xây dựng sẽ ảnh hưởng
đến môi trường của người sử dụng như thế nào:
+ Các máy chủ, máy trạm sẽ đặt ở đâu,
+ Ai sẽ là người sẽ sử dụng chúng,
+ Chức năng của mỗi máy,
+ Các tài liệu sẽ được sinh ra như thế nào,
+ Hệ thống sẽ thay đổi công việc của mỗi người
như thế nào.
11
3.4 Dàn bài của đặc tả chức năng (tt)
5. Mô tả các thành phần chức năng
- Mỗi thành phần, mỗi chức năng cần có mô tả chi tiết.
- Thành phần của phần cứng được liệt kê để giúp người sử
dụng thấy chúng tương tác qua lại với họ như thế nào
- Đối với mỗi thành phần của phần mềm cần chỉ ra:
+ Chức năng các quy trình xử lý,
+ Các thông tin vào, các thông tin ra, các xử lý,
+ Các dữ liệu được sử dụng.
12

3.4 Dàn bài của đặc tả chức năng (tt)
Có thể sử dụng các sơ đồ luồng dữ liệu, hoặc sơ đồ
luân chuyển tài liệu hoặc các sơ đồ cấu trúc khác.
Trong phần này cần có các mô hình:
+ Các mô hình chức năng nghiệp vụ.
+ Mô hình dòng dữ liệu.
+ Mô hình thực thể - quan hệ.
13
3.4 Dàn bài của đặc tả chức năng (tt)
6. Các yêu cầu hệ thống
+ Tính tương thích: các thành phần tương tác với
nhau như thế nào?
+ Tính tin cậy
+ Tính an toàn.
+ Tính dễ sử dụng…
+ Khả năng của hệ thống phản ứng
14
3.4 Dàn bài của đặc tả chức năng (tt)
7. Các sản phẩm chuyển giao khác
+ Các tài liệu
+ Huấn luyện, đào tạo…
8. Sự chấp nhận
- Người sử dụng sẽ kiểm tra hệ thống như thế nào để chấp
nhận nó.
- Một trong những vấn đề lớn nhất của tin học là người sử
dụng thường rất miễn cưỡng khi phải chấp nhận và thanh
toán tiền thực hiện hệ thống.
- Họ sợ rằng sau khi trả tiền, nếu hệ thống trục trặc có thể đội
dự án không sửa chữa, khắc phục kịp thời cho họ.
15

3.4 Dàn bài của đặc tả chức năng (tt)
9. Quản lý dự thay đổi
- Phải xử lý các thay đổi như thế nào sau khi DA bắt đầu
thực hiện.
-Thay đổi đặt tả chức năng có thể gây nên thay đổi các
khoản mục này và có thể làm chậm trễ dự án.
- Các thay đổi cần phải cố gắng để là ít nhất.
- Cần phải có một thủ tục để quản lý các thay đổi, đánh
giá tác động của nó cũng như kinh phí cần thiết để thực
hiện các thay đổi.
16
3.4 Dàn bài của đặc tả chức năng (tt)
-Thông báo cho toàn bộ những người sử dụng biết tất
cả những sự thay đổi cần phải thông qua người điều
phối dự án phía người sử dụng để đến đội dự án.
- Người sử dụng xắp thứ tự ưu tiên các thay đổi từ “bắt
buộc” đến “mong muốn”.
- Chúng ta đưa ra các giải pháp và thảo luận với người
sử dụng.
- Những thống nhất sẽ được đưa vào thực hiện.
17
3.4 Dàn bài của đặc tả chức năng (tt)
10. Trao đổi ý kiến giữa người sử dụng và tổ dự án
- Cần có quy định về những trao đổi ý kiến giữa người
sử dụng và đội DA ở cả mức kỹ thuật lẫn mức quản lý.
- Phía người dùng cần chỉ định ít nhất một người có đủ
hiểu biết và thẩm quyền để trả lời các câu hỏi liên quan
đến các vấn đề kỹ thuật (không chỉ ở giai đoạn này, mà
suốt trong tiến trình thực hiện dự án).
- Tương tự ở mức quản lý cũng cần có trao đổi ý kiến về

các vấn đề như kinh phí, nhân sự, lịch biểu, tiến độ, các
thay đổi
18
3.5 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 (PPP).
- Ngay từ khi chúng ta viết kế hoạch dự án ban đầu đến
thời điểm hiện tại và rất nhiều hiểu biết đã được bổ sung
trong thời gian đó.
- Chúng ta 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
19
3.5 Xem xét lại kế hoạch (tt)
* Vấn đề nhân sự:
- Những người được đề nghị thực hiện các nhiệm vụ đã
đảm bảo sẵn sàng khi cần đến hay chưa.
Đối với mỗi chức danh cần đặt câu hỏi:
- “Làm thế nào nếu người đó không có hoặc có nhưng
nhận nhiệm vụ muộn?”.
- Cần phải đề xuất kế hoạch thay thế.
+ Ta có thể đào tạo nguồn dự bị.
+ Dùng hệ thống "Người bạn" - lập trình viên có thể
được dự tính để làm bạn với lập trình viên chính,học tập
từ lập trình viên chính để có thể quản lý được công việc
nếu người này bỏ đi.
20
3.6 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%).
- 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.
21
3.7 Thiết kế tổng thể
- Không nên chỉ hình dung hệ thống sẽ "làm gì", mà cũng nên
hình dung ở mức tổng thể hệ thống sẽ hoạt động “như thế nào".
 Đó là nhiệm vụ của thiết kế mức tổng thể.
- Mô tả chung kiến trúc hệ thống.
- 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.
22
3.7 Thiết kế tổng thể (tt)
- Được tiến hành bằng phương pháp thiết kế có cấu trúc.
- Đó là phương pháp phân chia dần hệ thống thành các
thành phần nhỏ hơn, có thể quản lý và xây dựng.
- Thiết kế có thể bắt đầu từ trên xuống, hoặc từ dưới lên,
- Phương pháp từ dưới lên thường được sử dụng trong
trường hợp khi tổ hợp các phần mềm thành phần đã có
sẵn thành các môđun mới để tạo thành hệ thống.
23
3.7 Thiết kế tổng thể (tt)
- Có nhiều phương án, chúng ta phải tiến hành lựa chọn
phương án tốt nhất.

- Cần chú ý đến tác động của từng phương án đến các
yếu tố sau đây:
+ 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
24
3.8 Kết luận
Các mốc chính của giai đoạn phân tích là:
1. Đặc tả chức năng được hoàn thành, thông qua và ký
nhận.
2. 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.
3. 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.
4. Hoàn thành thiết kế mức tổng thể.
25
Câu hỏi thảo luận
1. Mục tiêu của giai đoạn phân tích là gì? Tại sao giai đoạn
này là giai đoạn quan trọng nhất đối với người sử dụng.
2. Tại sao phải xem lại kế hoạch dự án ban đầu và đánh
giá sau khi đã tiến hành phân tích.
3. Các bước của giai đoạn phân tích.