UML - Phân tích và thiết kế hướng đối tượng

Phân tích và thiết kế hướng đối tượng(Object Oriented System Analysis and Design) Giảng viên: Phạm Ngọc Nam Giới thiệu 4 ĐVHT = 60 tiết Học trên lớp + Bài tập lớn Điểm = Điểm thi + Điểm bài tập lớn (70%) + (30%) Điều kiện thi: Phải có bài tập lớn Bài tập lớn: Làm theo nhóm tối đa 5 sinh viên Nội dung: phân tích và thiết kế hệ thống sử dụng Rational Rose Đề tài: sinh viên tự chọn đề tài Mục đích của môn học Trang bị cho sinh viên một phương pháp có hệ thống để phân tích và thiết kế hệ thống Nội dung 1. Giới thiệu chung về phân tích và thiết kế hệ thống 2. Giới thiệu về phân tích và thiết kế hướng đối tượng với UML 3. Lập kế hoạch 4. Phân tích hệ thống 5. Thiết kế hệ thống 6. Triển khai hệ thống Tài liệu tham khảo Systems Analysis and Design with UML Version 2.0-An object oriented approach; Alan Dennis, Barbara Haley Wixom, David Tegarden. www.uml.org www.rational.com www.Google.com Chương 1. Giới thiệu chung về phân tích và thiết kế hệ thống 1.1 Giới thiệu 1.2 Quy trình phát triển hệ thống 1.3 Các phương pháp phát triển hệ thống 1.1 Giới thiệu 1.2 Quy trình phát triển hệ thống Lập kế hoạch (Planning) Vì sao phải xây dựng hệ thống ? Phân tích (Analysis) Ai sẽ sử dụng hệ thống, hệ thống sẽ làm gì, nó sẽ được dùng khi nào, ở đâu? Thiết kế (Design) Hệ thống sẽ làm việc như thế nào? Triển khai (Implementation) Triển khai hệ thống 1.2 Quy trình phát triển hệ thốngLập kế hoạch Xác định giá trị kinh doanh của hệ thống Phân tích tính khả thi Xây dựng kế hoạch công việc Xác định nguồn nhân lực cho dự án Điều khiển và quản lý dự án 1.2 Quy trình phát triển hệ thốngPhân tích Phân tích hệ thống Thu thập các nguồn thông tin Mô hình hoá quá trình Mô hình hóa dữ liệu 1.2 Quy trình phát triển hệ thốngThiết kế Xác định chiến lược thiết kế Thiết kế cấu trúc Thiết kế giao diện Thiết kế cơ sở dữ liệu Thiết kế chương trình 1.2 Quy trình phát triển hệ thốngTriển khai Xây dựng hệ thống Cài đặt hệ thống 1.2 Quy trình phát triển hệ thốngCác pha và kết quả của từng pha 1.3 Các phương pháp phát triển hệ thống Thiết kế cấu trúc (Structured design) Phương pháp thác nước (waterfall method) Phương pháp phát triển song song (Parallel development) Phương pháp phát triển nhanh ứng dụng (RAD) Phương pháp phát triển theo các pha Phương pháp xây dựng nguyên mẫu (prototyping) Thông thường (regular) Loại bỏ (throwaway) Phương pháp phát triển rất nhanh (Agile development) XP (extreme programming) 1.3.1 Thiết kế cấu trúc Dự án sẽ tiến triển từ bước này sang bước tiếp theo một cách có hệ thống Thông thường, một bước phải được hoàn thành trước khi bắt đầu bước tiếp theo 1.3.1 Thiết kế cấu trúcPhương pháp thác nước 1.3.1 Thiết kế cấu trúcPhương pháp thác nước Ưu điểm: Trước khi lập trình thì các yêu cầu về hệ thống được xác định rất chi tiết và đầy đủ => giảm thiểu được sự thay đổi về yêu cầu trong quá trình phát triển hệ thống Nhược điểm: Thời gian từ khi đề xuất dự án đến khi có sản phẩm cuối cùng thường rất dài (vài tháng -> vài năm) 1.3.1 Thiết kế cấu trúcPhương pháp phát triển song song 1.3.2 RAD Các nhân tố quan trọng: Công cụ CASE JAD Ngôn ngữ lập trình thế hệ thứ tư/ visual Công cụ tạo mã 1.3.2 RADPhương pháp phát triển theo pha 1.3.2 RADPhương pháp xây dựng nguyên mẫu thông thường 1.3.2 RADPhương pháp xây dựng nguyên mẫu loại bỏ 1.3.3 Lựa chọn phương pháp phù hợp Tiêu chí: Độ rõ ràng, đầy đủ của các yêu cầu của người sử dụng Khả năng, mức độ thành thạo về công nghệ Độ phức tạp của hệ thống Độ tin cậy của hệ thống Quỹ thời gian 1.3.3 Lựa chọn phương pháp phù hợp Chương 2: Giới thiệu về phân tích và thiết kế hướng đối tượng với UML 2.1 Giới thiệu 2.2 Các đặc điểm cơ bản của hệ thống hướng đối tượng 2.3 UML 2.0 2.4 Phân tích và thiết kế hướng đối tượng với UML 2.0 2.1 Giới thiệu Lịch sử phát triển của ngôn ngữ lập trình: First Generation (1954 – 1958) Fortran I Second Generation (1959 – 1961) Fortran II, Algol, Cobol Third Generation (1962 – 1970) PL/I, Pascal Object Oriented Languages Smalltalk, C++, Java 2.1 Giới thiệu Lịch sử phát triển của UML 2.1 Giới thiệu Lịch sử phát triển của UML Foundations of OO (Nygaard, Goldberg, Meyer,Stroustrup, Harel, Wirfs-Brock, Reenskaug,…) UML 1.1 (OMG Standard) UML 1.3 (extensibility) UML 1.4 (action semantics) UML 1.4.1 UML 2.0 2.1 Giới thiệu Thiết kế cấu trúc và thiết kế hướng đối tượng 2.1 Giới thiệu Thiết kế cấu trúc và thiết kế hướng đối tượng 2.2 Các đặc điểm cơ bản của hệ thống hướng đối tượng 2.2.1 Lớp và đối tượng 2.2.2 Phương thức và message 2.2.3 Tóm lược và ẩn thông tin (Encapsulation and Information Hiding) 2.2.4 Thừa kế (inheritance) 2.2.5 Đa hình thái và liên kết động (Polymorphism and Dynamic Binding) 2.2.1 Lớp và đối tượng Lớp (Class) – Template to define specific instances or objects Đối tượng (Object) – Instantiation of a class Thuộc tính (Attributes) – Describes the object Chức năng (Behaviors) – specify what object can do 2.2.1 Lớp và đối tượng 2.2.1 Lớp và đối tượng 2.2.2 Phương thức và message Phương thức (Methods) implement an object’s behavior Analogous to a function or procedure Messages are sent to trigger methods Procedure call from one object to the next 2.2.2 Phương thức và message 2.2.3 Tóm lược và ẩn thông tin Encapsulation combination of data and process into an entity Information Hiding Only the information required to use a software module is published to the user 2.2.4 Thừa kế Superclasses or general classes are at the top of a hierarchy of classes Subclasses or specific classes are at the bottom Subclasses inherit attributes and methods from classes higher in the hierarchy 2.2.4 Thừa kế 2.2.4 Thừa kế 2.2.5 Đa hình thái và liên kết động Polymorphism A message can be interpreted differently by different classes of objects Dynamic Binding Sometimes called late binding Delays typing or choosing a method for an object until run-time Static Binding Type of object determined at compile time 2.2.5 Đa hình thái và liên kết động 2. Function calls 2.3 UML 2.0 2.3.1 Giới thiệu UML 2.3.2 Biểu đồ cấu trúc 2.3.3 Biểu đồ chức năng 2.3.4 Các cơ chế mở rộng 2.3.5 Tóm tắt 2.3.1 Giới thiệu về UML "The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system.” UML chỉ đơn thuần là ngôn ngữ đồ hoạ để mô hình hoá chứ không phải là phương pháp để phát triển hệ thống Grady Booch, Ivar Jacobsen, Jim Rumbaugh Rational Software 2.3.1 Giới thiệu về UML UML 2.0 cung cấp 14 biểu đồ để mô hình hoá cấu trúc và chức năng của hệ thống, chia làm 2 nhóm: Biểu đồ mô hình cấu trúc Biểu đồ mô hình chức năng 2.3.2 Biểu đồ cấu trúc 6 loại biểu đồ cấu trúc: Biểu đồ lớp (Class) Biểu đồ đối tượng (Object) Biểu đồ gói (package) Biểu đồ triển khai (Deployment) Biểu đồ thành phần (Component) Biểu đồ cấu trúc phức hợp (Composite structure diagrams) 2.3.2 Biểu đồ cấu trúc Biểu đồ lớp (class diagram) Biểu diễn mối quan hệ giữa các lớp 2.3.2 Biểu đồ cấu trúc Biểu đồ đối tượng (object diagram) Biểu diễn mối quan hệ giữa các đối tượng 2.3.2 Biểu đồ cấu trúc Biểu đồ gói (package diagram) Biểu đồ gói gộp các thành phần khác nhau của UML (ví dụ: lớp) để tạo thành thành phần lớn hơn 2.3.2 Biểu đồ cấu trúc Biểu đồ triển khai (deployment diagram) Biểu diễn cấu trúc phần cứng và các thành phần phần mềm của hệ thống 2.3.2 Biểu đồ cấu trúc Biểu đồ thành phần (component diagram) Biểu diễn quan hệ giữa các thành phần của hệ thống 2.3.2 Biểu đồ cấu trúc Biểu đồ cấu trúc phức hợp (composite structure diagram) Minh hoạ chi tiết cấu trúc bên trong của một lớp 2.3.3 Biểu đồ chức năng 8 loại biểu đồ chức năng Biểu đồ hoạt động (activity diagram) Biểu đồ tương tác (interaction diagrams) Biểu đồ chuỗi tuần tự (sequence diagram) Biểu đồ cộng tác (communication/collaboration diagram) Biểu đồ khát quát tương tác (interaction overview diagram) Biểu đồ thời gian (timing diagram) Biểu đồ máy trạng thái (state machines) Máy trạng thái chức năng (behavior state machines) Máy trạng thái giao thức (protocol state machines) Biểu đồ ca sử dụng (use case diagram) 2.3.3 Biểu đồ chức năng Biểu đồ hoạt động (activity diagram) Được dùng để mô tả luồng công việc của hệ thống hoặc luồng hoạt động trong một ca sử dụng hoặc mô tả thiết kế chi tiết của một phương thức (method) 2.3.3 Biểu đồ chức năng Biểu đồ chuỗi tuần tự (sequence diagram) Mô tả các hoạt động của các đối tượng trong một ca sử dụng dựa vào thứ tự xuất hiện theo thời gian 2.3.3 Biểu đồ chức năng Biểu đồ cộng tác (collaboration diagram) Là cách biểu diễn khác của biểu đồ chuỗi tuần tự nhưng tập trung vào mối quan hệ và giao tiếp giữa các đối tượng 2.3.3 Biểu đồ chức năng Biểu đồ khát quát tương tác (interaction overview diagram) Được dùng để mô tả tương tác giữa các đối tượng trong các ca sử dụng phức tạp Ít được sử dụng Biểu đồ thời gian (timing diagram) Được dùng để mô tả tương tác giữa các đối tượng theo thời gian. Chủ yếu được dùng để mô tả sự thay đối trạng thái của đối tượng khi có tác động của một sự kiện theo thời gian. Được dùng để phát triển các hệ thống thời gian thực và hệ thống nhúng 2.3.3 Biểu đồ chức năng Biểu đồ máy trạng thái chức năng (behavior state machines) Được dùng để mô tả các trạng thái khác nhau mà các đối tượng của một lớp có thể có trong thời gian tồn tại của chúng. 2.3.3 Biểu đồ chức năng Biểu đồ máy trạng thái giao thức (protocol state machines) Được dùng để mô tả giao thức giữa các lớp Ví dụ: open database -> Query or update Biểu đồ ca sử dụng (use case diagram) Được dùng để mô tả tương tác giữa một hệ thống với người sử dụng hoặc với các hệ thống khác có tương tác với nó. Là công cụ để mô tả các yêu cầu của hệ thống Là một trong những công cụ quan trọng nhất trong phân tích và thiết kế hướng đối tượng 2.3.3 Biểu đồ chức năng 2.3.3 Biểu đồ chức năng 2.3.3 Biểu đồ chức năng 2.3.4 Các cơ chế mở rộng Ràng buộc (constraints) Dùng để biểu diễn ràng buộc và các quan hệ mà không thể biểu diễn được bằng UML Ràng buộc được đặt trong ngoặc { } 2.3.4 Các cơ chế mở rộng Nhãn:giá trị (tagged values) Là một cặp chuỗi ký tự: nhãn (tag) và giá trị (value) được dùng để bổ sung thông tin cho một phần tử nào đó (lớp, đối tượng, quan hệ …) Nhãn và giá trị được đặt trong ngoặc { } 2.3.4 Các cơ chế mở rộng Khuôn mẫu (stereotype) Cho phép mở rộng UML bằng cách sử dụng các phần tử mô hình hoá đã có sẵn trong UML Khuôn mẫu có thể sử dụng ràng buộc và tagged values Khuôn mẫu được đặt trong dấu > 2.3.5 Tóm tắt 2.4 Phân tích và thiết kế hướng đối tượng với UML 2.0 2.4.1 Đặc điểm cơ bản của OOAD 2.4.2 Ưu điểm của OOAD 2.4.3 The Unified Process 2.4.4 The MOOSAD 2.4.1 Đặc điểm cơ bản của OOAD Use-case driven Architecture Centric Cấu trúc phần mềm quyết định việc mô tả, xây dựng và viết tài liệu hệ thống 3 dạng cấu trúc của một hệ thống: Chức năng (functional view): chức năng bên ngoài của hệ thống từ góc nhìn của người sử dụng : biểu đồ ca sử dụng, biểu đồ hoạt động Cấu trúc tĩnh (static view): lớp, thuộc tính, phương thức, quan hệ Cấu trúc động (dynamic view): chức năng bên trong của hệ thống: biểu đồ máy trạng thái chức năng Iterative and Incremental 2.4.2 Ưu điểm của OOAD Việc chia nhỏ một hệ thống lớn thành các module sẽ giúp cho việc giải quyết vấn đề dễ dàng hơn, dễ chia sẻ giữa các thành viên của dự án và dễ dàng trao đổi với người dùng về các yêu cầu của hệ thống Dễ dàng sử dụng lại các module trong các dự án khác Tư duy suy nghĩ về đối tượng gần gũi với thực tế 2.4.2 Ưu điểm của OOAD 2.4.3 The Unified process Unified process là một phương pháp phát triển hệ thống trong đó quy định khi nào thì sử dụng các kỹ thuật UML và sử dụng chúng như thế nào trong quá trình phân tích và thiết kế hệ thống. Tác giả: Booch, Jacobsen, Rumbaugh Là phương pháp hướng đối tượng Không phải là một quy trình phát triển phần mềm hoàn thiện Không xét đến các vấn đề về phân bổ nhân lực, ngân quỹ, quản lý hợp đồng Không quy định về các hoạt động bảo trì hay hỗ trợ khách hàng Không xét đến các vấn đề tương tác giữa các dự án 2.4.3 The Unified process 2.4.3 The Unified process Pha khởi tạo (Inception): giống như pha lập kế hoạch Các bước liên quan: Mô hình hoá giá trị kinh doanh của hệ thống (business modeling) * Xác định yêu cầu (requirements)* Phân tích (analysis)* Thiết kế (design) Thực hiện (implementation) Kiểm tra (test) Môi trường phát triển (environment)* Kết quả: Phạm vi của dự án Các yêu cầu và ràng buộc quan trọng Kế hoạch dự án bước đầu Miêu tả tính khả thi và rủi ro của dự án Lựa chọn môi trường cần thiết để phát triển hệ thống 2.4.3 The Unified process Pha phát triển (elaboration): hoàn thiện mô hình kinh doanh, đánh giá lại rủi ro và hoàn thiện kế hoạch dự án Các bước liên quan: Thu thập yêu cầu (requirements) Phân tích (analysis)* Thiết kế (design)* Thực hiện (implementation) Kiểm tra (test) Triển khai (deployment) Quản lý cấu hình và thay đổi (configuration and change management) Kết quả: Biểu đồ cấu trúc và chức năng UML Phiên bản hoạt động đầu tiên của hệ thống 2.4.3 The Unified process Pha xây dựng (construction): tập trung chủ yếu vào lập trình Các bước liên quan: Thu thập yêu cầu (requirements) Phân tích (analysis) Thiết kế (design) Thực hiện (implementation)* Kiểm tra (test) Triển khai (deployment) Quản lý cấu hình và thay đổi (configuration and change management)* Kết quả: Phiên bản beta của hệ thống 2.4.3 The Unified process Pha chuyển tiếp (transition): tập trung chủ yếu vào kiểm tra và triển khai Các bước liên quan: Thu thập yêu cầu (requirements) Phân tích (analysis) Thiết kế (design) Thực hiện (implementation) Kiểm tra (test)* Triển khai (deployment)* Quản lý cấu hình và thay đổi (configuration and change management)* Kết quả: Phiên bản cuối cùng (release) của hệ thống Hướng dẫn sử dụng Kế hoạch hỗ trợ khách hàng, kế hoạch nâng cấp hệ thống 2.4.3 The Unified process Các bước kỹ thuật (Engineering workflows) Mô hình hoá giá trị kinh doanh (business modeling) Diễn ra chủ yếu trong pha khởi tạo Phát hiện vấn đề và xác định các dự án tiềm năng Xác định giá trị kinh doanh mà dự án đem lại Thu thập dữ liệu và mô hình hoá ca sử dụng có thể được sử dụng Xác định yêu cầu (requirements) Xác định yêu cầu về chức năng và cả không chức năng Yêu cầu được thu thập từ người sử dụng, người quản lý người sử dụng, khách hàng Phân tích Xây dựng biểu đồ cấu trúc và chức năng sử dụng UML Xác định các lớp có thể sử dụng lại Bước phân tích có thể được sử dụng lại bất kỳ lúc nào trong chu trình phát triển hệ thống 2.4.3 The Unified process Các bước kỹ thuật (Engineering workflows) Thiết kế Chuyển từ mô hình phân tích sang mô hình thiết kế Thiết kế giao diện, cơ sở dữ liệu, cấu trúc vật lý của hệ thống, thiết kế chi tiết các lớp Thực hiện (implementation) Lập trình: viết các lớp, chương trình và sử dụng các lớp trong thư viện Tích hợp các module Kiểm tra (Test) Kiểm tra tích hợp hệ thống, chức năng, kiểm tra khả năng chấp nhận của người sử dụng … Việc kiểm tra đuợc tiến hành trong suốt quá trình phát triển của hệ thống Triển khai (deployment) Đóng gói phần mềm, phân phối, cài đặt và beta testing 2.4.3 The Unified process Các bước hỗ trợ (Supporting workflows) Quản lý dự án (project management) Diễn ra trong suốt quá trình phát triển hệ thống Xác định và quản lý rủi ro Quản lý phạm vi dự án Quản lý về thời gian, chi phí… Quản lý cấu hình và thay đổi (configuration and change management ) Theo dõi và quản lý trạng thái và các phiên bản của hệ thống Quản lý việc thay đổi các phiên bản (người thay đổi, thời gian thay đổi…) Quản lý môi trường phát triển (environment) Quản lý các công cụ và môi trường phát triển cần thiết cho dự án Ví du: Rational Rose, Microsoft project, Microsoft Visual C++ 2.4.4 MOOSAD Chương 3. Lập kế hoạch 3.1 Khởi tạo dự án (Project initiation) 3.2 Quản lý dự án (Project Management) 3.1 Khởi tạo dự án 3.1.1 Giới thiệu 3.1.2 Yêu cầu hệ thống (system request) 3.1.3 Phân tích tính khả thi (feasibility analysis) 3.1.4 Lựa chọn dự án 3.1.1 Giới thiệu Nhu cầu kinh doanh Hội đồng duyệt dự án 3.1.1 Giới thiệu Hội đồng duyệt dự án (approval committee) Hội đồng chuyên trách họp thường kỳ (vd. 3 tháng 1 lần) 1 đơn vị chức năng hoặc cá nhân có thẩm quyền (vd. phòng quản lý dự án, giám đốc) 3.1.2 Yêu cầu hệ thống (system request) Tài liệu yêu cầu hệ thống gồm 5 thành phần: Chủ nhiệm dự án (project sponsor) Nhu cầu kinh doanh (business need) Yêu cầu kinh doanh (business requirements) Các giá trị kinh doanh ( business values) Các vấn đề đặc biệt (special issues) 3.1.2 Yêu cầu hệ thống (system request) Chủ nhiệm dự án (project sponsor) Người thuộc phòng kinh doanh Người thuộc phòng IT có thể là chủ nhiệm hoặc đồng chủ nhiệm dự án CIO, CEO Nhu cầu kinh doanh (business need): why? Xuất phát từ: Phòng kinh doanh Phòng IT Chuyên gia tư vấn bên ngoài Phát sinh khi: 1 chiến dịch kinh doanh mới cần được hỗ trợ cần tìm kiếm thêm khách hàng cần cải thiện việc trao đổi với nhà phân phối việc kinh doanh của công ty có vấn đề: cổ phiếu giảm, hỗ trợ khách hàng kém, bị cạnh tranh công nghệ mới nhiều tiềm năng xuất hiện 3.1.2 Yêu cầu hệ thống (system request) Yêu cầu kinh doanh (business requirement) Hệ thống sẽ làm gì Các chức năng của hệ thống Giá trị kinh doanh (business values) Giá trị hữu hình: ví dụ: 20 % giảm về chi phí Giá trị vô hình: ví dụ: cải thiện chất lượng dịch vụ khách hàng, cải thiện vị trí cạnh tranh Các vấn đề đặc biệt ví dụ: thời hạn hoàn thành Case study: CD selections Giới thiệu chung về công ty CD selections: 50 cửa hàng băng đĩa ca nhạc ở California Doanh số bán hàng: 50 triệu USD Tăng trưởng 3-5 % / năm Có website cung cấp các thông tin cơ bản về công ty như chỉ dẫn đường đi đến, giờ mở cửa, địa chỉ liên hệ Margaret Mooney, phó chủ tịch phụ trách thị trường có ý tưởng bán CD trên mạng Internet Case study: CD selections 3.1.3 Phân tích tính khả thi Khả thi về kỹ thuật (technical feasibility) Khả thi về kinh tế (economic feasibility) Khả thi về mặt tổ chức (organizational feasibility) 3.1.3 Phân tích tính khả thi Khả thi về kỹ thuật (technical feasibility) (can we build it ?) Mức độ quen thuộc với ứng dụng Mức độ quen thuộc với công nghệ Kích thước của dự án: Số lượng người tham dự thời gian độ phức tạp của hệ thống Sự tương thích của hệ thống mới với hệ thống đang tồn tại 3.1.3 Phân tích tính khả thi Khả thi về kinh tế (economic feasibility) (should we build it ?) Xác định các loại chi phí và lợi nhuận Chi phí phát triển hệ thống (1 lần) Chi phí vận hành (chi phí thường xuyên) Lợi nhuận hữu hình Lợi nhuận vô hình 3.1.3 Phân tích tính khả thi 3.1.3 Phân tích tính khả thi Khả thi về kinh tế (economic feasibility) (should we build it ?) Định lượng các loại chi phí và lợi nhuận Cố gắng định lượng các giá trị vô hình 3.1.3 Phân tích tính khả thi Khả thi về kinh tế (economic feasibility) (should we build it ?) Xác định dòng tiền mặt (cash flow): giá trị chi phí và lợi nhuận trong khoảng thời gian từ 3-5 năm 3.1.3 Phân tích tính khả thi 3.1.3 Phân tích tính khả thi Khả thi về kinh tế (economic feasibility) (should we build it ?) Xác định giá trị hiện tại Net present Value (NPV) Xác định tỷ lệ hồi vốn (Return on Investment) Xác định điểm hoà vốn (break even point) Vẽ đồ thị điểm hoà vốn 3.1.3 Phân tích tính khả thi Khả thi về kinh tế (economic feasibility) (should we build it ?) 3.1.3 Phân tích tính khả thi Khả thi về kinh tế (economic feasibility) (should we build it ?) 3.1.3 Phân tích tính khả thi Khả thi về kinh tế (economic feasibility) (should we build it ?) 3.1.3 Phân tích tính khả thi Khả thi về tổ chức Phân tích đánh giá mức độ hệ thống mới được chấp nhận bởi người sử dụng và khả năng tích hợp của hệ thống vào trong hệ thống đang vận hành trong công ty 2 cách đánh giá: Hệ thống mới có cùng định hướng với chiến lược phát triển của công ty? Phân tích ảnh hưởng hoặc bị ảnh hưởng của dự án đối với những người liên quan Người bảo trợ cho dự án Người sử dụng hệ thống Ban lãnh đạo công ty Case study: CD selections 3.1.4 Lựa chọn dự án 3 phương án: Thông qua Loại bỏ Xem xét lại Phụ thuộc vào: ROI, giá trị NPV của lợi nhuận, thời gian hoà vốn Số lượng và chất lượng các dự án khác 3.2 Quản lý dự án 3.2.1 Giới thiệu 3.2.2 Xác định kích thước dự án 3.2.3 Xây dựng và quản lý kế hoạch công việc 3.2.4