Giáo trình Công nghệ phần mềm - Bài 1: Phần mềm và công nghệ phần mềm - Lê Nguyễn Tuấn Thành

ững thách thức chính mà Công nghệ Phần mềm phải đối mặt là gì? 5. Sự khác nhau giữa Công nghệ Phần mềm và Khoa học Máy tính là gì? 6. Sự khác nhau giữa Công nghệ Phần mềm và Kỹ thuật Hệ thống (System Engineering) là gì? 7. Tiến trình phần mềm là gì? 8. Mô hình tiến trình phần mềm là gì? 9. Các chi phí của Công nghệ Phần mềm là gì? 10. Các phương thức Công nghệ Phần mềm là gì? 11. CASE (Computer-Aided Software Engineering) là gì? 1. Phần mềm là gì? What is the Software? 4 5 Tầm quan trọng 6  Nền kinh tế của TẤT CẢ các quốc gia phát triển phụ thuộc vào phần mềm,  Ngày càng có nhiều hệ thống được kiểm soát bởi phần mềm,  Chi tiêu cho phần mềm thể hiện một phần đáng kể của GNP1 ở tất cả các nước phát triển. [1] GNP (Gross National Product): Tổng sản lượng quốc gia Định nghĩa 7  Phần mềm là các chương trình máy tính và những tài liệu liên quan (đặc tả yêu cầu, mô hình thiết kế, tài liệu hướng dẫn sử dụng,)  Sản phẩm phần mềm được chia thành 2 loại: 1. Đại trà (Generic Product): được phát triển để bán cho một loạt các đối tượng khách hàng khác nhau. Ví dụ: các phần mềm PC như Excel hoặc Word 2. Chuyên biệt (Bespoke/Customised Product): được phát triển cho một khách hàng duy nhất theo yêu cầu của họ. Ví dụ: các phần mềm cho ngành thuế, ngân hàng, điện lực  Một phần mềm mới có thể được tạo ra bằng cách:  Phát triển những chương trình mới,  Cấu hình những hệ thống phần mềm chung,  Sử dụng lại phần mềm có sẵn Chi phí phần mềm (Software Costs) 8  Chi phí cho phần mềm thường chi phối chi phí cho hệ thống máy tính,  Chi phí của phần mềm trên PC thường lớn hơn chi phí phần cứng,  Chi phí cho phần mềm tập trung chủ yếu vào khâu bảo trì (maintain) hơn là khâu phát triển (develop).  Với những hệ thống có vòng đời dài, chi phí bảo trì có thể gấp nhiều lần chi phí phát triển Thuộc tính của Phần mềm TỐT 9  Khả năng bảo trì  Phần mềm phải phát triển để đáp ứng nhu cầu thay đổi  Đáng tin cậy  Phần mềm phải thực sự đáng tin cậy  Hiệu quả  Phần mềm không nên tạo ra việc sử dụng lãng phí tài nguyên hệ thống  Chấp nhận được  Phần mềm phải được chấp nhận bởi người dùng mà nó được thiết kế. Điều này có nghĩa là nó có thể được hiểu, sử dụng và tương thích với những hệ thống khác. 2. Công nghệ Phần mềm là gì? What is the Software Engineering? 10 Công nghệ Xây dựng 11 Những bước nào cần phải làm?  Quyết định cần xây những gì  Quyết định công trình sẽ trông như thế nào  Cần xây bao nhiêu tầng, mỗi tầng bao nhiêu phòng, mỗi phòng rộng bao nhiêu,  Quyết định vật liệu xây dựng  Lên kế hoạch dự án, lập lịch, làm việc nhóm  Mô phỏng và kiểm tra  Tiến hành xây dựng  Hoạt động và bảo trì Thành phần trong phát triển phần mềm 12 Không chỉ là kỹ năng công nghệ 13  Các trường đại học có xu hướng tập trung vào công nghệ, bỏ qua yếu tố con người và quá trình thực hiện.  Việc thực hiện theo quy trình có thể làm giảm tỷ lệ lỗi lên tới 75%  Trong thực tế, lập trình thường chiếm ít thời gian làm nhất trong toàn bộ quá trình thực hiện dự án! Khía cạnh của CNPM 14  Những quy trình cần thiết để chuyển một khái niệm thành một sản phẩm (deliverable) có thể tiến hóa theo thời gian  Làm việc với tài nguyên và thời gian bị giới hạn  Phải thỏa mãn một khách hàng  Quản lý rủi ro  Làm việc nhóm và giao tiếp Định nghĩa 15  Công nghệ phần mềm là một quy trình kỹ thuật (engineering discipline) liên quan đến tất cả khía cạnh của sản xuất phần mềm  CNPM liên quan tới các lý thuyết, phương pháp và công cụ cho việc phát triển phần mềm chuyên nghiệp  CNPM liên quan đến việc phát triển phần mềm hiệu quả về chi phí. Liên quan đến nhiều lĩnh vực 16  computer science (algorithms,data structures, languages,tools)  business/management (project mgmt,scheduling)  economics/marketing (selling,niche markets,monopolies)  communication (managing relations with stakeholders: customers, management,developers,testers, sales)  law (patents, licenses, copyrights,reverse engineering)  sociology (modern trends in societies, localization,ethics)  political science (negotiations; topics at the intersection of law, economics,and global societal trends; public safety)  psychology (personalities,styles, usability,what is fun)  art (GUI design,what is appealing to users) necessarily "softer"; fewer clearly right/wrong answers Các vai trò 17  Khách hàng (customer / client)  Muốn xây dựng phần mềm  Thường không biết rõ họ muốn những gì  Quản lý (managers)  Tạo kế hoạch, phối hợp thành viên trong nhóm  Khó dự đoán tất cả những vấn đề có thể phát sinh  Người phát triển (developers)  Thiết kế và viết mã nguồn  Khó có thể viết mã nguồn phức tạp cho những hệ thống lớn  Người kiểm thử (testers)  Thực hiện đảm bảo chất lượng (QA – Quality Assurance)  Không thể kiểm thử tất cả các trường hợp  Người dùng (Users)  Mua và sử dụng sản phẩm phần mềm  Hay thay đổi và có thể hiểu sai sản phẩm Làm ra Phần mềm là việc khó 18  Historically, ~ 85% of software projects "fail”.Why?  management sets unrealistic expectations; devs don't correct them  overestimating the positive impact of shiny new tools and hardware  hired developers based on availability despite warning signs  personality conflicts between developers  changes in rate structure requirements in middle of work  one delay causes another (dev delay leads to test delay, etc.)  hacks and shortcuts  developers end up working "death marches" (6-day, 10-hour weeks)  overestimating how nearly done you are ("I'm 90% there!")  software written doesn't match the spec  developer time taken away by other tasks  tons of bugs come out in testing  developers don't listen to testers; ignore severity of bugs reported  management breaking promises (bonuses, time off, etc.) Công nghệ Phần mềm vs. Khoa học Máy tính 19 Công nghệ Phần mềm Khoa học máy tính Liên quan đến việc thực hành để phát triển và phân phối phần mềm hữu ích Liên quan tới học thuyết và những nguyên lý cơ bản Các học thuyết khoa học máy tính vẫn chưa đủ để đóng vai trò là cơ sở hoàn chỉnh cho công nghệ phần mềm (không giống như các ngành Vật lý hay Kỹ thuật điện) Công nghệ Phần mềm vs. Kỹ thuật Hệ thống 20 Công nghệ Phần mềm Kỹ thuật Hệ thống Là một phần của Kỹ thuật Hệ thống liên quan tới phát triển hạ tầng phần mềm, điều khiển, ứng dụng và cơ sở dữ liệu trong hệ thống Liên quan đến tất cả khía cạnh của phát triển hệ thống dựa trên máy tính bao gồm phần cứng, phần mềm và quy trình kỹ thuật Kỹ sư hệ thống liên quan đến đặc tả hệ thống (system specification), thiết kế kiến trúc (architectural design), tích hợp (integration) và triển khai (deployment) Hoạt động trong CNPM 21  Vòng đời phát triển phần mềm (Software Development Lifecycle - SDLC) Chi phí của Công nghệ Phần mềm 22  Gần 60% chi phí dành cho việc phát triển (development), khoảng 40% cho việc kiểm thử (test).  Chi phí tiến hóa (evolution costs) thường vượt quá chi phí phát triển (development costs)  Phân phối chi phí phụ thuộc vào mô hình phát triển được sử dụng Phân phối Chi phí theo hoạt động (Activity cost distribution) 23 Các phương pháp CNPM (Software Engineering Methods) 24  Những cách tiếp cận có cấu trúc để phát triển PM:  Mô hình hệ thống (system models)  Hệ thống ký hiệu (notations)  Quy tắc (rules)  Tư vấn thiết kế (design advice)  Hướng dẫn quá trình (process guidance)  Miêu tả mô hình  Những miêu tả của mô hình đồ họa nên được tạo ra  Quy tắc  Những rằng buộc áp dụng cho mô hình hệ thống  Khuyến cáo  Những tư vấn cho thực hành thiết kế tốt  Hướng dẫn quá trình  Những hành động phải tuân theo Thách thức chính đối với CNPM 25  Tính không đồng nhất  Phát triển những kỹ thuật để xây dựng phần mềm đáp ứng những nền tảng và môi trường thực thi không đồng nhất  Sự phân phối  Phát triển những kỹ thuật để dẫn đến phân phối phần mềm nhanh hơn  Độ tin cậy  Phát triển những kỹ thuật để chứng minh phần mềm có thể được sự tin tưởng bởi người dùng Trách nhiệm chuyên môn và đạo đức 26  CNPM liên quan đến những trách nhiệm hơn là đơn giản chỉ áp dụng những kỹ năng kỹ thuật.  Kỹ sư phần mềm phải cư xử theo một cách trung thực và có trách nhiệm đạo đức nếu họ muốn được tôn trọng như các chuyên gia.  Hành vi đạo đức không chỉ đơn giản là tuân theo pháp luật Trách nhiệm chuyên môn 27  Tính bảo mật (confidentiality)  Các kỹ sư thường phải tôn trọng sự bảo mật của người sử dụng lao động hoặc khách hàng của họ bất kể một hợp đồng bảo mật chính thức có được ký kết hay không.  Năng lực (competence)  Các kỹ sư không nên làm sai lệch trình độ của mình. Họ không nên cố chấp nhận công việc vượt quá khả năng của mình.  Quyền sở hữu trí tuệ (intellectual property rights)  Các kỹ sư nên biết về luật pháp địa phương quy định việc sử dụng sở hữu trí tuệ như bằng sáng chế, bản quyền, Họ nên cẩn thận để đảm bảo rằng sở hữu trí tuệ của người sử dụng lao động và khách hàng được bảo vệ.  Lạm dụng máy tính (computer misuse)  KSPM không nên sử dụng kỹ năng của mình để lạm dụng máy tính của người khác.  Lạm dụng máy tính bao gồm từ những việc tương đối tầm thường (như chơi game trên máy tính của người sử dụng lao động) đến những việc nghiêm trọng (như phát tán virus). Bộ Quy tắc Đạo đức ACM/IEEE 28  Các hiệp hội chuyên nghiệp ở Hoa Kỳ đã hợp tác để đưa ra một bộ quy tắc đạo đức (Code of Ethics)  Thành viên của những tổ chức này đăng ký vào bộ quy tắc hành động khi họ gia nhập  Bộ quy tắc bao gồm 8 nguyên tắc liên quan đến hành vi và quyết định tạo bởi những kỹ sư phần mềm chuyên nghiệp Bộ quy tắc đạo đức – 8 Nguyên tắc 29 1. CỘNG ĐỒNG (PUBLIC)  Kỹ sư phần mềm (KSPM) phải hành động phù hợp với lợi ích cộng đồng 2. KHÁCH HÀNG VÀ NGƯỜI SỬ DỤNG LAO ĐỘNG (CLIENT & EMPLOYER)  KSPM phải hành động cho lợi ích tốt nhất của khách hàng và người sử dụng lao động phù hợp với lợi ích cộng đồng 3. SẢN PHẨM (PRODUCT)  KSPM phải đảm bảo rằng sản phẩm của họ và những thay đổi liên quan đáp ứng những chuẩn chuyên môn cao nhất có thể 4. ĐÁNH GIÁ (JUDGMENT)  KSPM phải duy trì tính toàn vẹn và độc lập trong sự đánh giá chuyên nghiệp của mình 5. QUẢN LÝ (MANAGEMENT)  Nhà quản lý và lãnh đạo CNPM phải đăng ký và thúc đẩy cách tiếp cận đạo đức đối với việc quản lý phát triển và bảo trì phần mềm 6. CHUYÊN NGHIỆP (PROFESSION)  KSPM phải nâng cao tính toàn vẹn và uy tín nghề nghiệp phù hợp với lợi ích cộng đồng 7. ĐỒNG NGHIỆP (COLLEAGUES)  KSPM phải công bằng và hỗ trợ đồng nghiệp của mình 8. BẢN THÂN (SELF)  KSPM phải tham gia học tập suốt đời liên quan đến thực hành nghề nghiệp và thúc đẩy tiếp cận đạo đức đối với việc thực hành này Tình huống khó xử về đạo đức (Ethical dilemmas) 30  Sự không đồng thuận về nguyên tắc với chính sách quản lý cấp cao  Người sử dụng lao động hành xử theo cách phi đạo đức và phát hành một hệ thống thiếu an toàn mà không hoàn thành việc thử nghiệm (testing)  Tham gia phát triển những hệ thống vũ khí quân sự hoặc hệ thống hạt nhân  Tóm tắt Công nghệ Phần mềm (1/2) 31  CNPM là một ngành kỹ thuật liên quan đến tất cả khía cạnh của sản phẩm phần mềm  Sản phẩm phần mềm bao gồm các chương trình được phát triển và tài liệu liên quan.  Những thuộc tính thiết yếu của sản phẩm là:  tính bảo trì (maintainability),  tính tin cậy (dependability),  tính hiệu quả (efficiency) và  tính sử dụng (usability)  Các phương pháp là những cách tổ chức để sản xuất phần mềm. Chúng bao gồm:  những đề xuất cho quá trình phải tuân theo,  bộ ký hiệu sử dụng,  những quy tắc chi phối việc miêu tả hệ thống được sản xuất và  những hướng dẫn thiết kế Tóm tắt Công nghệ Phần mềm (2/2) 32  KSPM có những trách nhiệm đối với nghề nghiệp và cộng đồng. Họ không nên chỉ đơn giản liên quan với những vấn đề kỹ thuật  Các hiệp hội chuyên nghiệp công bố bộ quy tắc ứng xử nhằm xác định những tiêu chuẩn hành vi mong muốn của những thành viên 3. Quản lý dự án Phần mềm Software Project Management 33 Mục tiêu 34  Giới thiệu quản lý dự án phần mềm và miêu tả những đặc điểm riêng biệt của nó  Giải thích những tác vụ chính được thực hiện bởi những người quản trị dự án (project managers)  Thảo luận về lập kế hoạch dự án và quá trình lập kế hoạch  Chỉ ra bằng cách nào những biểu diễn lịch trình đồ họa (graphial schedule) được sử dụng để quản lý dự án  Thảo luận những khái niệm về rủi ro (risk) và quá trình quản lý rủi ro Chủ đề được đề cập (Topics covered) 35  Những hoạt động quản lý (Management activities)  Lập kế hoạch dự án (project planning)  Lập lịch trình dự án (project scheduling)  Quản lý rủi ro (risk management) Quản lý Dự án Phần mềm (Software project management) 36  Liên quan đến những hoạt động để đảm bảo rằng:  phần mềm được phân phối đúng hạn (on time),  theo đúng lịch trình (on schedule) và  phù hợp với những yêu cầu của công ty phát triển cũng như công ty đặt hàng phần mềm  Quản lý dự án là cần thiết do quá trình phát triển phần mềm luôn luôn phụ thuộc vào ngân sách và những rằng buộc lịch trình được đặt ra bởi công ty phát triển phần mềm Những Hoạt động Quản lý (Management activities) 37  Viết đề xuất (proposal writing)  Lập kế hoạch và lịch trình dự án (project planning & scheduling)  Lập chi phí dự án (project costing)  Giám sát dự án và duyệt lại (project monitoring & reviews)  Lựa chọn và đánh giá nhân sự (personnel selection & evaluation)  Viết báo cáo và trình bày (report writing & presentations) Tính chất chung của Quản lý (Management commonalities) 38  Những hoạt động này không phải là đặc thù (peculiar) của quản lý phần mềm  Nhiều kỹ thuật trong các ngành quản lý dự án khác đều có thể áp dụng cho quản lý dự án phần mềm Lập nhân dự dự án (Project staffing) 39  Có thể không thể bổ nhiệm những người lý tưởng để làm việc trong một dự án, do:  Ngân sách dự án không cho phép sử dụng những nhân viên được trả lương cao  Nhân sự với kinh nghiệm thích hợp có thể không sẵn có  Công ty có thể mong muốn phát triển những kỹ năng cho nhân viên trong dự án phần mềm  Nhà quản lý phải làm việc với những rằng buộc này, đặc biệt khi có tình trạng thiếu nhân sự được huấn luyện Lập kế hoạch dự án (Project planning) 40  Có thể là hoạt động quản lý dự án tốn nhiều thời gian nhất  Là hoạt động liên tục từ lúc hình thành khái niệm ban đầu đến khi phân phối hệ thống.  Những kế hoạch phải thường xuyên được sửa lại khi có thông tin mới  Nhiều loại khác nhau của kế hoạch phải được phát triển để hỗ trợ kế hoạch dự án phần mềm chính, cái mà liên quan đến lịch trình và ngân sách dự án Các kiểu kế hoạch dự án 41 Kế hoạch Miêu tả Kế hoạch chất lượng (Quality plan) Miêu tả những thủ tục và tiêu chuẩn chất lượng được sử dụng trong một dự án Kế hoạch xác nhận (Validation plan) Miêu tả cách tiếp cận, tài nguyên và lịch trình được sử dụng cho xác nhận hệ thống Kế hoạch quản lý và cấu hình Miêu tả những thủ tục và cấu trúc quản lý cấu hình được sử dụng Kế hoạch bảo trì (Maintenance plan) Dự đoán những yêu cầu bảo trì của hệ thống, chi phí bảo trì và công sức được yêu cầu Kế hoạch phát triển nhân sự Miêu tả cách phát triển kỹ năng và kinh nghiệm cho những thành viên nhóm dự án Quá trình lập Kế hoạch Dự án (Project planning process) 42 Thiết lập những rằng buộc của dự án Đánh giá ban đầu về những thông số dự án Định nghĩa những cột mốc của dự án và sản phẩm tương ứng với từng mốc Chừng nào dự án còn chưa được hoàn thành hoặc bị hủy bỏ, lặp các bước sau: Xây dựng lịch trình dự án Khởi đầu những hoạt động theo lịch trình Chờ (một lúc) Xét lại tiến độ dự án (project progress) Xem lại ước lượng của những thông số dự án Cập nhật lịch trình dự án Tái thương lượng những rằng buộc dự án và sản phẩm đi kèm Nếu (gia tăng vấn đề) thì: Khởi đầu xét lại kỹ thuật và sử đổi có thể Kết thúc điều kiện nếu Kết thúc lặp Kế hoạch dự án (Project plan) 43  Kế hoạch dự án đề cập đến:  Các nguồn lực có sẵn cho dự án  Phân chia công việc (work breakdown)  Lịch trình cho công việc Cấu trúc kế hoạch dự án (Project plan structure) 44  Giới thiệu (introduction)  Tổ chức dự án (project organization)  Phân tích rủi ro (risk analysis)  Những yêu cầu tài nguyên phần cứng và phần mềm  Phân chia công việc (work breakdown)  Lịch trình dự án (project schedule)  Những cơ chế báo cáo và giám sát Lập lịch trình Dự án (Project scheduling) 45  Chia dự án thành các tác vụ và ước lượng thời gian & tài nguyên được yêu cầu để hoàn thành mỗi tác vụ  Tổ chức những tác vụ đồng thời để tối ưu hóa việc sử dụng nhân lực (workforce)  Tối giản hóa những phụ thuộc giữa các tác vụ để giảm độ trễ do một tác vụ phải đợi tác vụ khác hoàn thành Việc lập lịch trình phụ thuộc vào trực giác và kinh nghiệm của những nhà quản trị dự án Quá trình lập Lịch trình Dự án (Project scheduling process) 46 Vấn đề trong việc lập Lịch trình (Scheduling problems) 47  Ước lượng độ khó của những vấn đề và từ đó chi phí để phát triển một giải pháp là khó  Năng suất (productivity) không tỷ lệ với số lượng người làm việc trên một tác vụ  Thêm nhân lực vào một dự án quá hạn khiến nó càng bị trễ hơn do các chi phí giao tiếp  Việc không mong đợi luôn luôn xảy ra. Do đó phải luôn có dự phòng (contingency) trong việc lập kế hoạch Biểu đồ hình cột và Mạng hoạt động (Bar charts and activity networks) 48  Những ký hiệu đồ họa được sử dụng để minh họa lịch trình dự án  Hiển thị sự phân nhỏ dự án thành các tác vụ. Những tác vụ không nên quá nhỏ  Nên kéo dài trong khoảng 1 hay 2 tuần  Biểu đồ hoạt động hiển thị sự phụ thuộc giữa các tác vụ và đường găng (critical path)  Biểu đồ hình cột hiển thị lịch trình theo thời gian biểu Thời lượng Tác vụ và Những phụ thuộc (Task durations and dependencies) 49 Chỉ ra tên hoạt động, ai có trách nhiệm với mỗi hoạt động và khi nào hoạt động đó được lên lịch bắt đầu hoặc kết thúc. Biểu đồ thanh (Sơ đồ Gantt) (1/2) 50 Stt Task Start on Day Task Duration Start Date End Date 1 Đồng bộ DB giữa 2 hệ thống backup VN (114) và backup Sing (230) 0 8 30-09-16 07-10-16 2 Test KT đồng bộ giữa 2 hệ thống backup VN và backup Sing 10 2 10-10-16 11-10-16 5 Test đồng bộ với khách hàng lần 1 12 6 12-10-16 17-10-16 6 Xây dựng Testcases 18 5 18-10-16 22-10-16 7 KT xây dựng mô hình đồng bộ mới (db phân tán) gồm 4 servers 23 3 23-10-16 25-10-16 9 Test KT 26 2 26-10-16 27-10-16 10 Test đồng bộ với khách hàng lần 2 28 7 28-10-16 03-11-16 11 Các bộ phận nghiệm thu pha 2 35 1 04-11-16 04-11-16 Biểu đồ thanh (Sơ đồ Gantt) (2/2) 51 0 5 10 15 20 25 30 Đồng bộ DB giữa 2 hệ thống backup VN (114) và backup Sing (230) Test KT đồng bộ giữa 2 hệ thống backup VN và backup Sing Test đồng bộ với khách hàng lần 1 Xây dựng Testcases KT xây dựng mô hình đồng bộ mới (db phân tán) gồm 4 servers Test KT Test đồng bộ với khách hàng lần 2 Các bộ phận nghiệm thu pha 2 Kết thúc pha 2 Time & Task Duration T a sk s Biểu đồ Grantt của Pha 2 [20/09 - 18/10] • Microsoft Excel, Microsoft Project. Công cụ vẽ Sơ đồ Gantt 52 Đường thời gian của hoạt động (Activity timeline) 53 Biểu đồ Phân bổ Nhân viên (Staff allocation) 54 Biểu đồ Mạng lưới Hoạt động  Các sơ đồ mạng lưới hoạt động chỉ ra các lệ thuộc giữa các hoạt động khác nhau tạo thành dự án:  Công việc: các việc cần làm  Sự kiện: Kết quả công việc  Mối liên hệ giữa các công việc (CV)  Có CV trước không có CV sau  Có CV sau không có CV trước  Có cả CV trước và sau Biểu đồ Mạng lưới 56  Có 2 dạng biểu diễn  AOA: các mũi tên chỉ các công việc còn các nút chỉ các sự kiện  AON: Các công việc được biểu diễn trên các nút Biểu đồ Mạng lưới (Sơ đồ AOA) Đường găng  Công việc găng (critical task) là các công việc có trữ lượng thời gian (thời gian tự do) bằng 0. Tức là các công việc đã bị fix cứng thời gian.  Đường găng (critical path) là đường dài nhất đi xuyên mạng đi từ thời điểm bắt đầu tới thời điểm kết thúc đi qua các công việc găng (critical task)  Ý nghĩa: Độ dài của đường găng trên trục thời gian, chính là thời lượng nhỏ nhất có thể để dự án hoàn thành theo kế hoạch, tức là thời gian hoàn thành dự án Phương pháp Đường găng CPM (1/3) 59  ES (Early Start):Thời gian bắt đầu sớm  EF (Early Finish):Thời gian kết thúc sớm  LS (Late Start):Thời gian bắt đầu muộn  LF (Late Finish):Thời gian kết thúc muộn  Tg là thời gian hoàn thành  ES của các công việc ngay khi bắt đầu quy định là 1  ES = max (EF của các công việc trước đó) + 1  EF = ES + Tg – 1  LF = LS + Tg – 1  Tg tự do = LS – ES Phương pháp Đường găng CPM (2/3) 60 Phương pháp Đường găng CPM (3/3) 61 Đường găng là đường chứa toàn các công việc có thời gian tự do là 0. Trong sơ đồ trên, đường B → E là đường găng. Bài tập: Tìm Đường găng của Dự án sau Công việc Thời gian (ngày) Công việc trước A 5 B 6 C 10 A,B D 7 B E 3 C F 4 C,D G 9 E,F Quản trị Rủi ro (Risk management) 63  Một rủi ro là xác suất xảy ra một số tình huống bất lợi  Những rủi ro dự án tác động đến lịch trình hoặc tài nguyên  Những rủi ro sản phẩm tác động đến chất lượng hoặc hiệu suất của phần mềm được phát triển  Những rủi ro kinh doanh tác động đến công ty phát triển hoặc đặt hàng (procure) phần mềm  Quản trị rủi ro liên quan đến xác định những rủi ro và thiết lập những kế hoạch để tối giản hóa ảnh hưởng của chúng đối với dự án 64 Các rủi ro phần mềm (1/2) (Software risks) 65 Rủi ro Mức ảnh hưởng Miêu tả Nhân sự biến động (Staff turnober) Dự án Nhân viên có kinh nghiệm rời khỏi dự án trước khi nó hoàn thành Sự quản lý thay đổi (Management change) Dự án Có một sự thay đổi trong cách quản lý công ty với những ưu tiên khác Phần cứng không có sẵn (Hardward unavailability) Dự án Phần cứng cần thiết cho dự án không được phân phối theo như lịch trình Yêu cầu thay đổi (Requirements change) Dự án và Sản phẩm Có một số lượng lớn sự thay đổi trong yêu cầu hơn dự kiến Đặc tả bị trễ (Specification delays) Dự án và Sản phẩm Đặc tả của những giao diện cần thiết không sẵn có trên lịch trình Ước tính thấp kích thước (Size underestimate) Dự án và Sản phẩm Kích thước của hệ thống đã bị ước tính thấp Các rủi ro phần mềm (2/2) (Software risks) 66 Rủi ro Mức ảnh hưởng Miêu tả Công cụ CASE kém hiệu quả Sản phẩm Những công cụ CASE hỗ trợ dự án không thực thi như dự kiến Công nghệ thay đổi (Technology changes) Kinh doanh Công nghệ nền tảng mà hệ thống được xây dựng trên đó bị thay thế bởi công nghệ mới Sự cạnh tranh sản phẩm (Product competition) Kinh doanh Một sản phẩm cạnh tranh đã được đưa ra thị trường trước khi sản phẩm hoàn thiện Quá trình quản trị rủi ro (1/2) (The risk management process) 67  Xác định rủi ro (risk identification)  Xác định những rủi ro dự án, sản phẩm và kinh doanh  Phân tích rủi ro (risk analysis)  Đánh giá khả năng và hậu quả của những rủi ro này  Lập kế hoạch rủi ro (risk planning)  Xây dựng những kế hoạch để tránh hoặc tối giản hóa ảnh hưởng của rủi ro  Giám sát rủi ro (risk monitoring)  Giám sát rủi ro xuyên suốt dự án Quá trình quản trị rủi ro (2/2) (The risk management process) 68 Xác định Rủi ro (Risk identification) 69  Rủi ro công nghệ (technology risks)  Rủi ro con người (people risks)  Rủi ro tổ chức công ty (organizational risks)  Rủi ro yêu cầu (requirement risks)  Rủi ro ước lượng (estimation risks) Rủi ro và Những loại rủi ro (1/2) (Risks and risk types) 70 Loại rủi ro Những rủi ro có thể Công nghệ • Cơ sở dữ liệu được sử dụng trong hệ thống không thể xử lý nhiều giao dịch (transactions) trong một giây như mong đợi • Những thành phần hệ thống nên được sử dụng chứa những khiếm khuyết dẫn đến hạn chế chức năng của chúng Con người • Không thể tuyển dụng nhân sự có những kỹ năng được yêu cầu • Nhân sự chủ chốt ốm và không sẵn sàng trong những thời điểm quan trọng • Khóa huấn luyện yêu cầu cho nhân sự không sẵn có Tổ chức công ty • Công ty phải tái cấu trúc và quản lý khác chịu trách nhiệm dự án • Những vấn đề tài chính công ty buộc ngân sách dự án giảm Công cụ • Mã được sinh ra bởi những công cụ CASE không hiệu quả • Công cụ CASE không thể được tích hợp Rủi ro và Những loại rủi ro (2/2) (Risks and risk types) 71 Loại rủi ro Những rủi ro có thể Yêu cầu • Thay đổi yêu cầu dẫn đến việc thiết kế lại phần lớn được đề xuất • Khách hàng không hiểu được ảnh hưởng của việc yêu cầu thay đổi Ước lượng • Thời gian yêu cầu để phát triển phần mềm bị ước lượng quá thấp • Tỷ lệ khuyết khiếm phải sửa bị ước lượng quá thấp • Kích thước của phần mềm bị ước lượng quá thấp Phân tích rủi ro (1/4) (Risk analysis) 72  Đánh giá xác suất và tầm quan trọng của từng rủi ro  Xác suất có thể là: rất thấp, thấp, trung bình, cao hoặc rất cao  Những tác động rủi ro có thể là: thảm khốc (catastrophic), nghiêm trọng (serious), chấp nhận được (tolerable) hoặc không đáng kể (insignificant) Phân tích rủi ro (2/4) (Risk analysis) 73 Rủi ro (Risk) Xác suất (Probability) Tác động (Effects) Những vấn đề tài chính công ty buộc ngân sách dự án giảm Thấp Thảm khốc Không thể tuyển dụng nhân sự có những kỹ năng được yêu cầu Cao Thảm khốc Nhân sự chủ chốt ốm và không sẵn sàng trong những thời điểm quan trọng Trung bình Nghiêm trọng Những thành phần hệ thống nên được sử dụng chứa những khiếm khuyết dẫn đến hạn chế chức năng của chúng Trung bình Nghiêm trọng Thay đổi yêu cầu dẫn đến việc thiết kế lại phần lớn được đề xuất Trung bình Nghiêm trọng Công ty phải tái cấu trúc và quản lý khác chịu trách nhiệm dự án Cao Nghiêm trọng Phân tích rủi ro (3/4) (Risk analysis) 74 Rủi ro (Risk) Xác suất (Probability) Tác động (Effects) Cơ sở dữ liệu được sử dụng trong hệ thống không thể xử lý nhiều giao dịch trong một giây như mong đợi Trung bình Nghiêm trọng Thời gian yêu cầu để phát triển phần mềm bị ước lượng quá thấp Cao Nghiêm trọng Công cụ CASE không thể được tích hợp Cao Chấp nhận được Khách hàng không hiểu được ảnh hưởng của việc yêu cầu thay đổi Trung bình Chấp nhận được Khóa huấn luyện yêu cầu cho nhân sự không sẵn có Trung bình Chấp nhận được Tỷ lệ khuyết khiếm phải sửa bị ước lượng quá thấp Trung bình Chấp nhận được Phân tích rủi ro (4/4) (Risk analysis) 75 Rủi ro (Risk) Xác suất (Probability) Tác động (Effects) Kích thước của phần mềm bị ước lượng quá thấp Cao Chấp nhận được Mã được sinh ra bởi những công cụ CASE không hiệu quả Trung bình Không đáng kể Lập kế hoạch rủi ro (Risk planning) 76  Chiến thuậtTránh (Avoidance strategies)  Xác suất phát sinh rủi ro bị giảm đi  Chiến thuậtTối giản (Minimization strategies)  Ảnh hưởng của rủi ro với dự án hoặc sản phẩm sẽ bị giảm đi  Kế hoạch Dự phòng (Contingency plans)  Nếu phát sinh rủi ro, những kế hoạch dự phòng sẽ được sử dụng để ứng phó với rủi ro đó Những chiến thuật quản trị rủi ro (1/2) (Risk management strategies) 77 Rủi ro Chiến thuật Vấn đề tài chính công ty Chuẩn bị một tài liệu tóm lược cho quản lý cấp cao để chỉ ra rằng dự án đang có đóng góp rất quan trọng như thế nào cho các mục tiêu kinh doanh Vấn đề tuyển dụng Cảnh báo khách hàng về những khó khăn tiềm ẩn và khả năng bị chậm trễ, tiến hành điều tra những thành phần mua vào Nhân viên ốm Tổ chức lại nhóm sao cho có thêm nhiều chồng lặp (overlap) trong công việc và con người do đó các thành viên hiểu được công việc của nhau Thành phần kiếm khuyết Thay thế những thành phần khiếm khuyết tiềm ẩn bằng cách mua vào những thành phần có độ tin cậy cao Những chiến thuật quản trị rủi ro (2/2) (Risk management strategies) 78 Rủi ro Chiến thuật Thay đổi yêu cầu Lấy được thông tin truy xuất để đánh giá tác động của việc thay đổi yêu cầu, tối đa hóa thông tin ẩn trong thiết kế Tái cấu trúc công ty Chuẩn bị một tài liệu tóm lược cho quản lý cấp cao để chỉ ra rằng dự án đang có đóng góp rất quan trọng như thế nào cho các mục tiêu kinh doanh Hiệu suất cơ sở dữ liệu Xem xét khả năng mua một cơ sở dữ liệu hiệu suất cao hơn Thời gian phát triển bị ước lượng quá thấp Xem xét mua thêm thành phần, xem xét sửa dụng một trình tạo mã chương trình tự động Giám sát rủi ro (Risk monitoring) 79  Đánh giá thường xuyên từng rủi ro để quyết định liệu nó đang trở nên ít xảy ra hơn hay ngược lại  Đánh giá liệu ảnh hưởng của rủi ro có thay đổi không  Mỗi rủi ro chính nên được thảo luận tại các buổi họp quản lý tiến trình Tóm tắt Quản lý dự án phần mềm (1/2) 80  Quản lý dự án tốt là cần thiết cho sự thành công của dự án  Bản chất phi vật thể của phần mềm gây khó khăn cho việc quản lý  Những nhà quản lý có vai trò đa dạng nhưng những hoạt động quan trọng nhất của họ là:  lập kế hoạch (planning),  ước lượng (estimating) và  lập lịch trình (scheduling)  Lập kế hoạch và ước lượng là những quá trình lặp lại được tiếp tục trong suốt quá trình thực hiện dự án Tóm tắt Quản lý dự án phần mềm (2/2) 81  Một cột mốc (milestone) dự án là một trạng thái có thể dự đoán được, tại đó một báo cáo chính thức về tiến độ được trình bày cho ban quản lý  Lập lịch trình dự án liên quan đến chuẩn bị những biểu diễn đồ họa khác nhau để hiển thị những hoạt động của dự án, khoảng thời gian và nhân sự  Quản lý rủi ro liên quan đến xác định những rủi ro có thể ảnh hưởng đến dự án và lập kế hoạch để đảm bảo rằng những rủi ro này không trở thành những các mối đe dọa lớn 4. Quy trình Phần mềm Software Processes 82 Mục tiêu 83  Giới thiệu những mô hình quy trình phát triển phần mềm  Mô tả những mô hình quy trình chung và khi nào chúng có thể được sử dụng  Mô tả phác thảo những mô hình quy trình cho yêu cầu kỹ thuật (requirement engineering), phát triển phần mềm (software development), kiểm thử (testing) và tiến hóa (evolution)  Giải thích mô hình RUP (Rational Unified Process)  Giới thiệu công nghệ CASE để hỗ trợ những hoạt