Bài giảng Dự án phần mềm - Bài 1: Các khái niệm cơ bản của dự án phần mềm - Thạc Bình Cường

ự án bị dự án quản lý;
  Hồ sơ dự án kém chất lượng;
  Chậm tiến độ, tiêu vượt quá kinh phí;
  Chất lượng dự án không đảm bảo.
 12
1.2. QUẢN LÝ DỰ ÁN LÀ GÌ? (tiếp theo)
• Các thuộc tính của dự án IT:
  Kết quả bàn giao có thể là ít hữu hình;
  Phạm vi có thể khó kiểm soát;
  Kỹ năng, kinh nghiệm, thái độ và kỳ vọng trái ngược nhau;
  Có thể bất đồng về mục tiêu kinh doanh;
  Thay đổi quan trọng về tổ chức;
  Các yêu cầu, phạm vi, và lợi nhuận chính xác có thể rất khó xác định;
  Sự thay đổi nhanh chóng về công nghệ.
• Lưu ý:
  Quản lý dự án thành công chính là vấn đề về con người;
  Khám phá các nguồn hỗ trợ và ngăn trở;
  Nhìn bản chất, không tin hiện tượng;
  Người khác có cách nhìn khác nhau;
  Thiết lập kế hoạch chỉnh sửa dễ dàng;
  Dám đối mặt với sự kiện;
  Sử dụng quản trị để hỗ trợ cho các mục đích của dự án;
  Thời gian mục tiêu đối với từng nhiệm vụ không được giống như đã nêu trong
 kế hoạch;
  Đọc lại phạm vi và các mục tiêu của dự án mỗi tuần một lần;
  Không ngạc nhiên.
 13
1.3. NÓI VỀ NGƯỜI QUẢN LÝ DỰ ÁN
• Người kỹ sư mang nhiều đặc tính của công nghệ.
• Người quản lý mang nhiều đặc tính của nghệ thuật.
• Dự án nhỏ thì người kỹ sư kiêm người quản lý dự án. Dự án lớn sẽ cần nhóm quản lý
 dự án.
• Bảng phân vai trong dự án:
  Người quản lí dự án (PM - Project Manager): Chịu trách nhiệm chính về kết quả
 của dự án. Có vai trò chủ chốt trong việc xác định các mục đích và mục tiêu,
 xây dựng các kế hoạch dự án, đảm bảo dự án được thực hiện có hiệu lực và
 hiệu quả.
  Người tài trợ dự án (PS - Project Sponsor). Cấp tiền cho dự án hoạt động, phê
 duyệt dự án, quyết định cho dự án đi tiếp hay cho chết giữa chừng.
  Tổ dự án (PT - Project Team). Hỗ trợ cho PM để thực hiện thành công dự án.
 Bao gồm những người vừa có kỹ năng (skill) và năng lực (talent).
  Khách hàng (Client): Thụ hưởng kết quả dự án. nêu yêu cầu, cử người hỗ trợ
 dự án. Là người chủ yếu nghiệm thu kết quả dự án.
  Ban lãnh đạo (Senior Mangement): Bổ nhiệm PM và PT, tham gia vào việc hình
 thành và xây dựng dự án.
  Các nhóm hỗ trợ (có thể có nhiều hay ít, tuỳ từng dự án): Ban điều hành
 (Steering Committee), nhóm tư vấn, nhóm kỹ thuật, nhóm thư ký, ... 14
1.3. NÓI VỀ NGƯỜI QUẢN LÝ DỰ ÁN (tiếp theo)
 Tổ dự án
 Người sử dụng Ban lãnh đạo
 Người quản lý 
 dự án
 Ban chỉ đạo Người tài trợ 
 dự án dự án
 15
1.3. NÓI VỀ NGƯỜI QUẢN LÝ DỰ ÁN (tiếp theo)
• Trách nhiệm của QLDA:
 Trách nhiệm chính Chi tiết
 Nêu ra những điểm bao quát chung Về công việc, cấu trúc phân việc, lịch biểu và 
 ngân sách 
 Trao đổi với các đồng nghiệp Bao gồm các báo cáo, biểu mẫu, bản tin, hội 
 họp và thủ tục làm việc. Ý tưởng là trao đổi 
 cởi mở và trung thực trên cơ sở đều đặn
 Động viên, khuấy động tinh thần làm việc Bao gồm khích lệ, phân việc, mời tham gia 
 và ủy quyền
 Định hướng công việc Bao gồm điều phối, theo dõi, thu thập hiện 
 trạng và đánh giá hiện trạng
 Hỗ trợ cho mọi người
 16
1.3. NÓI VỀ NGƯỜI QUẢN LÝ DỰ ÁN (tiếp theo)
• Chọn nhân sự cho dự án:
  Kiến thức kỹ thuật;
  Chuyên môn đặc biệt;
  Đã có kinh nghiệm;
  Đã tham gia dự án nào chưa?
  Quyền lực của phòng, ban của người đó?
  Hiện có tham gia dự án nào khác không?
  Khi nào kết thúc?
  Dành bao nhiêu thời gian cho dự án?
  Khối lượng công việc chuyên môn hiện nay;
  Quan hệ đồng nghiệp;
  Có hăng hái tham gia;
  Có truyền thống làm việc với hiệu quả cao không?
  Có ngăn nắp và quản lý thời gian tốt không?
  Có tinh thần trách nhiệm không?
  Có tinh thần hợp tác không?
  Thủ trưởng của người đó có ủng hộ không?
 17
1.3. NÓI VỀ NGƯỜI QUẢN LÝ DỰ ÁN (tiếp theo)
• Xây dựng tập thể vững mạnh:
  Bổ nhiệm người phụ trách;
  Phân bổ trách nhiệm;
  Khuyến khích tinh thần đồng đội;
  Làm phát sinh lòng nhiệt tình;
  Thành lập sự thống nhất chỉ huy;
  Quản lý trách nhiệm;
  Cung cấp môi trường làm việc tốt;
  Trao đổi với đồng nghiệp.
• Sức ép với QLDA: Kinh tế, marketing, các chuẩn về công nghệ, mục tiêu, uy tín danh
 dự, nguồn nhân lực, nhân sự, thủ tục hành chính, quan hệ với người đặt hàng, môi
 trường kinh doanh.
• Phẩm chất QLDA: Trung thực, toàn tâm toàn ý, khả năng diễn đạt, khả năng chia sẻ
 thông cảm với người khác, nhất quán, kiên nhẫn, tính kiên quyết, khách quan, tầm
 nhìn xa trông rộng, 
 18
2. PHÁT TRIỂN PHẦN MỀM TRUYỀN THỐNG
• Sơ lược về quá trình – dự án truyền thống:
 Dạng Văn bản không Sơ đồ luồng Chương trình nguồn Vạch ranh giới cấu hình
 theo thể thức
 Hoạt động Yêu cầu phân tích Thiết kế chương Lập trình và kiểm Tích hợp theo tỷ lệ mở 
 trình thử rộng và kiểm sửa
 Sản phẩm Tài liệu Tài liệu Chương trình Vạch ranh giới yếu ớt
 Các hoạt động kế tiếp: Yêu cầu – thiết kế - lập trình – tích hợp – kiểm sửa
 100% Bắt đầu tích hợp
 Điểm gián 
 đoạn thiết kế 
 chậm
 (% lập trình) lập (%
 Tiến độ phát triển triển phát độ Tiến Ngày đạt mục 
 tiêu gốc
 Lịch trình dự án
 19
2. PHÁT TRIỂN PHẦN MỀM TRUYỀN THỐNG (tiếp theo)
• Các kinh nghiệm của quá trình phát triển phần mềm:
  Quá trình phát triển là không dự đoán được rất cao. Chỉ có 10% dự án là đúng
 hạn và ngân sách;
  Các nguyên tắc quản lý là khó phân biệt được thành công hay thất bại như các
 tiến bộ công nghệ;
  Các mức vụn vặt và làm lại phần mềm là xác định trong tiến trình tăng trưởng.
• Hai bước cơ bản để xây một chương trình:
 Phân tích và lập trình sẽ bao gồm các công việc
 sáng tạo mà nó đóng góp trực tiếp tới tính hữu Phân tích
 dụng của sản phẩm.
 Lập trình
 20
2. PHÁT TRIỂN PHẦN MỀM TRUYỀN THỐNG (tiếp theo)
• Mô hình thác nước cổ điển:
 Yêu cầu hệ
 thống
 Yêu cầu phần
 mềm
 Phân tích
 Thiết kế
 chương
 Lập trình
 Kiểm sửa
 Thực hiện
 21
2. PHÁT TRIỂN PHẦN MỀM TRUYỀN THỐNG (tiếp theo)
• Chi phí:
 STT Hoạt động Chi phí (%)
 1 Quản lý 5
 2 Xác định yêu cầu 5
 3 Thiết kế 10
 4 Mã hóa và kiểm sửa 30
 5 Tích hợp và kiểm sửa 40
 6 Triển khai 5
 7 Môi trường 5
 22
2. PHÁT TRIỂN PHẦN MỀM TRUYỀN THỐNG (tiếp theo)
• Sơ lược rủi ro:
 Yêu cầu Sơ lược rủi ro Sơ lược rủi ro Kiểm sửa
 Định hướng 
 Cao Điều khiển 
 tập trung chu 
 chu kỳ quản 
 kỳ giải trình 
 lý rủi ro
 rủi ro
 Chiều hướng rủi ro của dự dự của án rủi hướng ro Chiều Chu kỳ khai Chu kỳ chi tiết 
 Thấp thác rủi ro hóa rủi ro
 Vòng đời dự án
 23
2. PHÁT TRIỂN PHẦN MỀM TRUYỀN THỐNG (tiếp theo)
• Lập tài liệu và điều khiển dự án:
  Nhà dự thầu (contractor) chuẩn bị một tài liệu hợp đồng để phân phát cho
 khách hàng duyệt mà nó bảo đảm nắm bắt được các mẫu phát triển qua các
 bước trung gian;
  Khách hàng có góp ý trở lại (trong vòng 15 đến 30 ngày);
  Nhà thầu sau khi xem xét lại các ý kiến của khách hàng và nộp lại bản cuối cùng
 để duyệt (cũng trong vòng 15 tới 30 ngày).
• Các kinh nghiệm cụ thể:
 Các kinh nghiệm ban đầu thường thấy thông qua thiết kế trên giấy và qua đó
 thường rất tóm tắt.
  Vi phạm về sự mã hoá muộn trong vòng đời dự án;
  Việc tích hợp hệ thống gây ra ác mộng về các vấn đề thể hiện không nhìn thấy
 trước và sự nhập nhằng về các giao diện giữa chúng;
  Thờì gian và tài chính là các áp lực cho hệ thống làm việc;
  Một sản phẩm không tối ưu nhưng đã chót làm và không có thời gian thiết
 kế lại;
  Một sản phẩm rất yếu ớt, khó bảo trì và phân phối rất muộn mằn.
 24
2. PHÁT TRIỂN PHẦN MỀM TRUYỀN THỐNG (tiếp theo)
• Tóm tắt các vấn đề về thực tiễn:
  Việc tích hợp kéo dài và phá vỡ thiết kế sau này;
  Sự giải quyết rủi ro quá muộn;
  Có yêu cầu phân rã theo chức năng;
  Mối quan hệ giữa các cổ đông đối nghịch nhau;
  Chỉ tập trung vào tài liệu và các cuộc họp rà soát lại.
• Năm cải tiến cần thiết đối với mô hình thác nước:
  Hoàn thiện thiết kế chương trình trước khi bắt đầu phân tích và mã hóa (xây
 dựng) chương trình;
  Bảo trì hiện hành và hoàn thiện tài liệu;
  Làm các nhiệm vụ hai lần nếu có thế;
  Lập kế hoạch, điều khiển và theo dõi kiểm tra;
  Trao đổi sâu sát và thu hút khách hàng.
 25
2. PHÁT TRIỂN PHẦN MỀM TRUYỀN THỐNG (tiếp theo)
• Danh sách dẫn đầu 10 độ đo phần mềm công nghiệp của Boehm:
  Sửa chữa sau khi đã phân phối tốn kém hơn 100 lần so với sửa ngay từ đầu;
  Bạn có thể nén lịch trình thời gian kế hoạch tới 25%, nhưng không thể nhiều
 hơn được;
  Với $1 cho phát triển thì cần $2 cho bảo trì;
  Chi phí chủ yếu là hàm của dòng chương trình nguồn;
  Sự thay đổi con người sẽ gây ra sự khác nhau rất lớn của năng suất (in
 productivity);
  Tỷ lệ chi phí giữa phần mềm và phần cứng là 85:15 và ngày càng tăng lên;
  Chỉ có khoảng 15% của các chi phí phần mềm là liên quan đến lập trình;
  Các hệ thống phần mềm chi phí gấp 3 lần so với chương trình phần mềm riêng
 rẽ. Các sản phẩm phần mềm hệ thống chi phí còn gấp cả 9 lần;
  Duyệt qua phần mềm chỉ bắt được 60% lỗi;
  80% đóng góp đến từ 20% các nhà góp vốn.
• Luật 80/20:
  80% công nghệ tiêu thụ bởi 20% yêu cầu;
  80% chi phí phần mềm tiêu thụ bởi 20% thành phần;
  80% sai sót là nguyên nhân gây ra bởi 20% thành phần;
  80% phần mềm bị loại bỏ và phải làm lại là do nguyên nhân của 20% sai sót;
  80% nguồn tài nguyên tiêu thụ là do 20 % thành phần;
  80% công nghệ là hoàn thành bởi 20% công cụ;
  80% sự tiến bộ của dự án được thực hiện bởi 20 % con người. 26
3. SỰ TIẾN HÓA NỀN KINH TẾ PHẦN MỀM
• Nền kinh tế phần mềm;
• Sự ước lượng chi phí phần mềm thực tế.
 27
3.1. NỀN KINH TẾ PHẦN MỀM
• Mô hình chi phí phần mềm bao gồm 5 tham số:
  Kích cỡ của sản phẩm cuối thông thường số dòng chương trình nguồn.
  Tiến trình xử lý để đưa ra sản phẩm cuối.
  Khả năng của nhân sự.
  Môi trường – Các công cụ và kỹ thuật.
  Chất lượng yêu cầu của sản phẩm cuối.
• Công thức lượng giá chi phí:
 Chi phí = (Nhân sự)(Môi trường)(Chất lượng)(Kích thướctiến trình).
• Ba giai đoạn phát triển phần mềm được thể hiện ở hình vẽ sau:
 28
3.1. NỀN KINH TẾ PHẦN MỀM (tiếp theo)
 ROI 
 phần
 Chi phí Chi mềm
 Kích thước phần mềm
 - 1960s-1970s - 1980s-1990s - 2000 và sau đó
 - Mô hình thác nước - Cải tiến tiến trình - Sự phát triển lặp đi lặp lại
 - Thiết kế chức năng - Dựa vào bao bọc - Thành phần
 - Tỷ lệ phi kinh tế - Tỷ lệ phi kinh tế - Kết quả đầu tư
 Sự phù hợp môi trường, kích thước và các công nghệ tiến trình
 Môi trường/Công cụ Môi trường/Công cụ Môi trường/Công cụ
 Tập quán Không lỗi thời, riêng rẽ Không lỗi thời, tích hợp
 Kích thước: Kích thước: Kích thước:
 100% tập quán 30% dựa vào thành phần cơ bản 70% dựa vào thành phần cơ bản
 70% tập quán 30% tập quán
 Tiến trình: Tiến trình: Tiến trình:
 Theo trường hợp đặc biệt Có thể lặp lại Quản lý/phân phối
Hiệu năng của dự án điển hình
 Khả năng dự đoán tồi Không có khả năng dự đoán Có khả năng dự đoán
 Luôn luôn: Không thường xuyên: Thường xuyên:
 Vượt quá ngân sách Đúng ngân sách Đúng ngân sách
 Vượt quá lịch trình Đúng lịch trình Đúng lịch trình
 29
3.2. SỰ ƯỚC LƯỢNG CHI PHÍ PHẦN MỀM THỰC TẾ
• Đánh giá các điểm chức năng:
  Sự biến đổi chương trình nguồn làm cơ sở cho việc đánh giá;
  Sử dụng các điểm chức năng “Function Points” để đánh giá chi phí:
 . Các dữ liệu đầu vào của người sử dụng
 . Các dữ liệu đầu ra
 . Nhóm các dữ liệu cục bộ
 . Giao diện dữ liệu ngoài
 . Các dạng câu hỏi ngoài
• Độ chính xác: Toàn bộ độ chính xác của việc đánh giá chi phí phần mềm hiện tại
 được mô tả như là " 20 % sự chính xác , 70 % về thời gian“
• Tiến trình chi phí nổi bật được mô tả như sau:
 “Dự án này phải có giá trị là $X để 
 Nhà quản lý phần mềm, nhà chiến thắng trong nền thương mại này”
 quản lý kiến trúc phần mềm, 
 nhà quản lý phát triển phần 
 mềm, nhà quản lý định giá 
 phần mềm “Đây là sự biện hộ 
 Mô hình chi phí nào đó về giá trị đó”
 Các rủi ro, sự lựa chọn, 
 trả giá, thay thế
 Chi phí ước lượng
 30
3.2. SỰ ƯỚC LƯỢNG CHI PHÍ PHẦN MỀM THỰC TẾ (tiếp theo)
• Các thuộc tính của đánh giá tốt:
  Việc đánh giá phải được nhận thức và hỗ trợ bởi mọi các thành viên tham gia
 dự án;
  Cán bộ quản lý dự án, đội kiến trúc, đội phát triển và đội kiểm thử trong từng
 công việc của họ;
  Việc đánh giá phải được chấp nhận bởi tham vọng của toàn bộ các cổ đông
 nhưng cần hiện thực;
  Việc đánh giá dựa vào mô hình xác định chuẩn với nền tảng tin cậy;
  Việc đánh giá dựa trên các kinh nghiệm của các dự án trước;
  Việc đánh giá được chi tiết cụ thể và đặc biệt quan tâm hiểu biết tới lĩnh vực
 rủi ro.
 31
4. CẢI TIẾN NỀN KINH TẾ PHẦN MỀM
• Năm tiêu chí cải tiến nền kinh tế phần mềm:
  Giảm kích cỡ của phần mềm;
  Cải tiến tiến trình phát triển phần mềm;
  Sử dụng các nhân sự có kỹ năng và nhóm đội tốt hơn;
  Sử dụng môi trường, công cụ phát triển phần mềm tốt hơn;
  Thoả hiệp, cân nhắc, hoặc thúc đẩy các mặt còn yếu dựa vào ngưỡng chất
 lượng.
• Giảm kích thước phần mềm:
  Lựa chọn ngôn ngữ lập trình;
  Áp dụng các phương pháp hướng đối tượng và mô hình hoá trực quan;
  Sử dụng lại phần mềm;
  Các thành phần phần mềm thương mại hoá.
• So sánh các điểm chức năng qua ví dụ ngôn ngữ:
  1,000,000 dòng lệnh - ngôn ngữ Assembly;
  400,000 dòng lệnh - ngôn ngữ C;
  220,000 dòng lệnh - ngôn ngữ Ada 83;
  175,000 dòng lệnh - ngôn ngữ Ada 95 hoặc C++.
 32
4. CẢI TIẾN NỀN KINH TẾ PHẦN MỀM (tiếp theo)
• Phương pháp hướng đối tượng và mô hình trực quan:
  Việc nắm bắt tính trừu tượng hoá của phần mềm dẫn đến giao tiếp và làm việc
 theo đội nhóm tốt hơn;
  Việc tích hợp liên tục thường xuyên dẫn đến nhận biết các rủi ro sớm và hạn
 chế chi phí chỉnh sửa;
  Kiến trúc hướng đối tượng đảm bảo phân tách các thành phần của hệ thống và
 tạo bức tường ngăn cản các sự cố lan truyền nhằm giảm chi phí;
  Mô hình hướng đối tượng và trực quan tạo ra kiến trúc vững chắc nhằm tạo ra
 sản phẩm sạch và giảm chi phí.
• Sử dụng lại phầm mềm:
  Kiến trúc phần mềm chung;
  Môi trường phát triển;
  Các hệ điều hành;
  Hệ thống quản trị CSDL;
  Các sản phẩm trên mạng;
  Các ứng dụng văn phòng.
 33
4. CẢI TIẾN NỀN KINH TẾ PHẦN MỀM (tiếp theo)
• Chi phí sử dụng lại và lập lịch:
 Giải pháp nhiều dự án: Thao tác với giá trị cao tên đơn vị 
 đầu tư, các sản phẩm thương mại điển hình
 5 giải pháp dự án: trên 125% chi phí và trên 150% thời gian
 2 giải pháp dự án: trên 50% chi phí và 100% thời gian
 1 giải pháp dự án: $N và M tháng
 Phát triển chi phí và lập lịch tài tài nguyên lịch lập và phí chi triển Phát
 Số dự án sử dụng thành phần có thể tái sử dụng được
 34
CÂU HỎI THẢO LUẬN
 Xu hướng nền kinh tế phần mềm trong những năm gần đây như thế nào?
 35
TÓM LƯỢC CUỐI BÀI
 • Phát triển phần mềm thông thường ngày nay không đáng tin
 cậy và lạc hậu.
 • Mô hình thác nước cần cải tiến để làm việc thỏa đáng. Thực
 tiễn thông thường đảm bảo các tiêu chuẩn cho việc cải tiến
 trong tương lai và thay đổi các phương pháp phát triển
 phần mềm.
 • Đánh giá phần mềm phải dựa vào việc phân tích cụ thể và
 được hỗ trợ bởi các thành viên.
 • Cải tiến nền kinh tế phần mềm phải dựa vào việc giảm kích
 thước, sử dụng các thành viên có kỹ năng và cân đối các chỉ
 tiêu phần mềm tương lai.
 36