CHƯƠNG 1: GIỚI THIỆU

- Thuật ngữ: CNPM 1968-1969

- CNPM – IEEE: Áp dụng pp tiếp cận có hệ thống, có kỷ luật và được lượng hóa trong phát triển, vận hành và bảo trì phần mềm; Nghiên cứu các pp tiếp cận được dùng trong (1)

- Mục tiêu: Chất lượng cao; Đúng kế hoạch thời gian; Trong phạm vi ngân sách dự kiến; Giá thành hạ

- Các giai đoạn: Phân tích; Thiết kế; Cài đặt; Kiểm thử; Bảo trì (50% bảo trì hoàn thiện)

- Công sức từng giai đoạn 40 (Kiểm thử) – 20 (cài đặt) – 40 (…)

- Thành viên đội phát triển pm (8): Nhà phân tích yc; Nhà thiết kế; Lập trình viên; Nhà kiểm thử; Người hướng dẫn; Nhóm bảo trì; Thủ thư; Nhóm quản lý cấu hình.

- Chương trình là một đoạn mã lệnh có thể thực thi được trên máy tính

- Phân loại PM:

• + Hệ thống: Compiler, HĐH
• + Thời gian thực: PM đk CN, điều độ điện
• + Tác nghiệp: CSDL
• + Hệ thống nhún: ĐK máy móc, robot, tự động
• + Khoa học KT: Tính toán
• + PM cá nhân: Văn phòng, trò chơi
• + Trí tuệ nhân tạo: Hệ CG, mạng Neuron

- Đặc tính: Phát triển ko chế tạo; Cá thể hơn sx lắp ráp hàng loạt; Lỗi thời; Độ phức tạp; Vô hình; Cơ hội kinh doanh, cạnh tranh.

CHƯƠNG 2: CÁC MÔ HÌNH TIẾN TRÌNH

- Tiến trình: là cách thức tạo ra phần mềm

1. Xây dựng và hiệu chỉnh

- Không tính trước; Ko đặc tả hay thiết kế; 1 phiên bản; sửa chữa theo yêu cầu khách hang; Trong hệ thống nhỏ 100-200loc.

2. Thác nước

- Royce 1970 – Không thay đổi yêu cầu; Đơn giản, dễ giải thích; Hoạt động tuần tự

- Verification: thỏa mãn đặc tả; Validation: thỏa mãn người dùng.

- Đặc tính: Lỗi giai đoạn trước phản hồi giai đoạn sau; Hoàn thành -> Tài liệu+Chấp nhận.

- Ưu: Kỹ thuật cao; Quy định tốt về tài liệu cho mỗi giai đoạn, kiểm chứng cẩn thận, ứng dụng rộng rãi.

- Nhược: Quá nhiều kiểm thử…; Hướng tài liệu khó hình dung

- Hạn chế: Không cung cấp hd trong giai đoạn phát triển; SX hơn là sáng tạo; Ko có hđ lặp, chỉ tạo ra sản phẩm cuối cùng; Chờ đợi lâu…

3. Chữ V

- Biến đổi của thác nước; Kiểm thử đơn vị kiểm chứng thủ tục; Tích hợp … thiết kế hệ thống; Chấp nhận … hợp lệ của yêu cầu.

4. Bản mẫu

- Khó khăn để nhận thức đầy đủ; Tạo bản mẫu khác làm bản thật (Nhanh, rẻ, ý tưởng trước); Nghiên cứu yêu cầu và thiết kế được lặp lại; Giảm rủi ro; Khi yêu cầu không rõ ràng;

- 3 dạng: Trên giấy hoặc PC; Cài đặt tập con các chức năng; Chương trình đã có.

- Ưu: Dễ dùng, Dễ thỏa yêu cầu, Vấn đề phát hiện sớm, Chất lượng cao hơn, Dễ bảo trì, Tiết kiệm công sức.

- Nhược: Thật có nhiều chức năng hơn, Đội ngũ nhiều kinh nghiệm

- Khuyến cáo: Yêu cầu ko rõ, Minh họa giao diện, Thay đổi yêu cầu khó, Ko nâng cao chất lượng, Phải có kế hoạch và kiểm soát.

5. Tăng trưởng

- Từng bước chuyển giao người dùng; Tránh “Big Bang”; Người dùng tham gia lập kế hoạch; Tránh dư thừa chức năng; Dễ ước lượng thời gian, công sức; Tập trung cốt lõi

6. Định khung nhanh

- Gia tăng nhanh; Chu kỳ ngắn 60-90; Khả năng tái sử dụng; Nhiều nhóm mỗi nhóm làm 1 RAD;

- Khuyết: Cần nhân lực dồi dào; 2 bên cam kết; RAD ko phải tốt cho mọi ứng dụng

7. Xoắn ốc

- Boehm 1988; Kết hợp phát triển, quản lý rủi ro; Mỗi lần lặp là một đường vòng quanh; 4 hđ chính (Lập kế hoạch, Phân tích rủi ro, Kỹ nghệ, Khách hàng đánh giá)

8. Hướng đối tượng

- Vòi phun nước (các giai đoạn gối lên nhau); Quan trọng nhất là lặp (giữa các giao đoạn, một phần giai đoạn); Giảm bớt nhân lực bảo trì.

9. RUP

- Bổ sung cho UML; Tiếp cận lặp (use case mô hình hóa yêu cầu);

- Các giai đoạn: Bắt đầu (phạm vi, giới hạn, usecase, kiến trúc, dự đoán chi phí, kế hoạch); Sửa soạn (CSKT, hỗ trợ công cụ); Xây dựng (SX tiến trình); Chuyển tiếp (phát hành)

So sánh các mô hình

CHƯƠNG 3: ƯỚC LƯỢNG CHI PHÍ

- Các yếu tố cần UL: Kích thước phần mềm; Công sức phát triển; Thời gian thực hiện; Số người tham gia

- Nguyên tắc: Phân rã chức năng; Ước lượng từng chức năng; Dựa trên kinh nghiệm, dữ kiện

- Ước lượng kích thước phần mềm: Trực tiếp (Qua dòng lệnh) Gián tiếp (Điểm chức năng)

- Qua dòng lệnh: 1 dòng (LOC); ngàn dòng KDSI; phụ thuộc ngôn ngữ

+ Vấn đề: Kích thước các giai đoạn khác nhau; Ngôn ngữ LT khác nhau; Tính số dòng mã lệnh khó; Sinh mã tự động, giao diện trực tiếp; Giá thành phụ thuộc vào ước lượng LOC

- Qua điểm chức năng: Độc lập với ngôn ngữ; (Số In, Out, Yêu cầu, Tập tin truy cập, Giao diện;

- Ước lượng chi phí: Dựa trên kích thước, độ phức tạp; Dữ liệu quá khứ; Chi phí tỉ lệ với công sức; Đơn vị: Người/tháng, người/ngày;

- Từ trên xuống: Khởi đầu hệ thống, đánh giá toàn thể; Ko cần keiesn thức KTHT; Tính chi phí tích hợp, quản lý…; Có thể ko đúng chi phí giải quyết;

- Từ dưới lên: Khởi đầu thành phần, đánh giá từng thành phần; KT và thành phần HT xác định; Chính xác khi HT chi tiết; Có thể ko đúng chi phí hoạt động HT

- Ý kiến chuyên gia;  Theo giải thuật: Walstion & Felix, Bailey & Basili, COCOMO;

- COCOMO 81: tất cả PM đều được phát triển từ đầu;

- COCOMO 2: những cách tiếp cận khác nhau;

Ví dụ 1:

Ví dụ 2:

Ví dụ 3:

CHƯƠNG 4: QUẢN LÝ NHÂN SỰ

- Yếu tố tác động lên việc chọn nhân sự: Kinh nghiệm về lĩnh vực ứng dụng;Kinh nghiệm về nền tảng; Kinh nghiệm về ngôn ngữlập trình; Khả năng giải quyết vấn đề; Nền tảng giáo dục; Khả năng giao tiếp; Tính thích ứng; Tính cách.

- Yếu tố chi phối đến công việc nhóm: Kết cấu nhóm; Sự gắn kết nhóm; Các giao tiếp nhóm; Tổ chức của nhóm;

- Một nhóm hiệu quả phải có sự cân bằng của tất cả các tính cách:

• Người hướng tới công việc thường mạnh về kỹ thuật
• Người hướng tới bản thân thường thúc đẩy sự hoàn thành công việc
• Người hướng tới sự tương tác giúp cho sự giao tiếp trong nhóm thuận tiện hơn

CHƯƠNG 5: QUẢN LÝ CHẤT LƯỢNG

- Chất lượng phần mềm là mức độ thỏa mãn của người dùng về : Tính chính xác; Độ tin cậy; Tính dùng được; Dễ bảo trì; Dễ bảo trì; Dễ kiểm thử; Tính khả chuyển…

- Các loại chuẩn: Sản phẩm; Quy trình; Tư liệu

- Cấu trúc của kế hoạch chất lượng: Giới thiệu sản phẩm; Các kế hoạch cho sản phẩm; Các mô tả quy trình; Mục tiêu chất lượng; Rủi ro và quản lý rủi ro.

CHƯƠNG 6: QUẢN LÝ CẤU HÌNH

- QLCH (CM) là sự phát triển và ứng dụng của các thủ tục và chuẩn để quản lý một sản phẩm phần mềm đang tiến hóa, có thể được xem là một phần của quy trình quản lý chất lượng tổng quan hơn.

- Các thành phần cấu hình: Các đặc tả; Các thiết kế; Các chương trình; Dữ liệu kiểm thử; Dữ liệu kiểm thử; Tài liệu hướng dẫn người sử dụng

- Tại sao 1 hệ thống tồn tại ở nhiều cấu hình khác nhau?: Các cấu hình được tạo ra: Cho các máy/ hệ điều hành khác nhau; Cung cấp các chức năng khác; Đáp ứng các yêu cầu đặc biệt của người dùng.

- Ai là người đưa ra các yêu cầu thay đổi đối với hệ thống? : Các yêu cầu thay đổi đối với hệ thống phần mềm có thể bắt nguồn từ: Người dùng; Nhà phát triển; Áp lực thị trường.

- Phiên bản (version): Một thể hiện của hệ thống mà nó khác biệt chức năng với các thể hiện khác của hệ thống theo cách nào đó

- Biến thể (variant): Một thể hiện của hệ thống mà nó giống về chức năng nhưng khác về phi chức năng với các thể hiện khác của hệ thống các thể hiện khác của hệ thống

- Phát hành (release): Một thể hiện của hệ thống mà nó được phân phối cho người dùng bên ngoài nhóm phát triển.

- Ba kỹ thuật cơ bản để xác minh thành phần: Đánh số phiên bản; Xác minh dựa trên thuộc tính; Xác minh hướng tới sự thay đổi.

- Xây dựng hệ thống là quy trình biên dịch và liên kết các bộ phận phần mềm vào một chương trình mà nó thực hiện trên một cấu hình đích cụ thể.

CHƯƠNG 7: LẬP KẾ HOẠCH DỰ ÁN VÀ KIỂM SOÁT DỰ ÁN

- Các lớp đặc trưng của dự án: Đặc trưng của sản phẩm; Đặc trưng của qui trình; Đặc trưng của nguồn lực

- Nguyên tắc chung: Chia nhỏ dự án thành các công việc kiểm soát được;  Mỗi công việc có một mốc thời gian và nguồn lực có thể kiểm soát được tiến độ; Các công việc thường được thực hiện theo một trật tự nào đó.

- Sơ đồ PERT chương 7 (cắt giảm)

CHƯƠNG 8: ĐẶC TẢ YÊU CẦU

- Một yêu cầu là sự diễn đạt cách hoạt động mong muốn

- Các yêu cầu tập trung vào nhu cầu của khách hàng chứ không phải tập trung vào giải pháp hay sự thực hiện

- Được thực hiện bởi nhà phân tích yêu cầu hay nhà phân tích hệ thống; Kết quả cuối cùng là tài liệu đặc tả các yêu cầu phần mềm

- Các yếu tố hàng đầu làm cho dự án thất bại: Các yêu cầu không hoàn chỉnh; Thiếu sự tham gia của người sử dụng; Các mong muốn không thực tế; Thiếu sự hỗ trợ quản trị; Thay đổi các yêu cầu và các đặc tả; Thiếu việc lập kế hoạch; Hệ thống không được cần nữa.

- Các thành viên tham gia trong hoạt động thu thập yêu cầu:

• Clients: trả tiền cho phần mềm được phát triển
• Customers: mua phần mềm sau khi nó được phát triển
• Người dùng: sử dụng hệ thống
• Chuyên gia về lĩnh vực: biết rõ vấn đề mà phần mềm phải tin học hóa
• Nhà nghiên cứu thị trường: thực hiện các cuộc khảo sát để xác định các xu hướng tương lai và những khách hàng tiềm xác định các xu hướng tương lai và những khách hàng tiềm năng
• Luật sư và kiểm toán viên: biết rõ các yêu cầu của luật pháp, chính phủ hay sự an toàn
• Kỹ sư phần mềm và các chuyên gia công nghệ khác: đảm bảo phần mềm là khả thi về kinh tế và công nghệ

- Các cách thu thập yêu cầu

• Phỏng vấn những người tham gia trong hệ thống
• Phỏng vấn những người tham gia vào hệ thống theo nhóm
• Xem lại các tài liệu có sẵn
• Quan sát hệ thống hiện hành (nếu hệ thống tồn tại)
• Theo người dùng để học về nghiệp vụ của họ một cách chi tiết hơn
• Sử dụng các chiến lược xác định vấn đề như thiết kế ứng dụng chung (Joint Application Design)
• Vận dụng trí tuệ (brainstorming) của người dùng hiện tại và tiềm năng để có được các yêu cầu

- Phân loại: các yêu cầu chức năng; các yêu cầu phi chức năng.

- Sự ưu tiên hóa phân tách các yêu cầu vào ba hạng mục sau

• • Cần thiết: phải được đáp ứng một cách hoàn toàn
  • Mong muốn: mong được đáp ứng nhưng không nhất thiết
  • Tùy chọn: có thể được đáp ứng nhưng có thể bị loại trừ

- Các loại tài liệu yêu cầu: Định nghĩa các yêu cầu; Đặc tả các yêu cầu

- Đặc trưng: Chính xác (Correct): Nhất quán (Consistent); Không mơ hồ (Unambigious); Hoàn chỉnh (Complete); Khả thi (Feasible); Có liên quan (Relevant) ; Có thể kiểm thử (Testable); Có thể theo vết (Traceable).

- Lưu đồ dòng dữ liệu:

• Thuận lợi:Cung cấp một mô hình trực quan của một chức năng mức cao của hệ thống được đề nghị và của các phụ thuộc dữ liệu giữa các quy trình khác nhau
• Khó khăn : Có thể làm tăng tính mơ hồ đối với nhà phát triển phần mềm người ít biết rõ về vấn đề đang được mô hình hóa

- Lược đồ use case: Các thành phần:

• Đường biên của hệ thống (được ký hiệu bởi hình chữ nhật)
• Tác nhân (được ký hiệu bởi hình người hay << >>)
• Trường hợp sử dụng –use case -(được ký hiệu bằng hình oval). Một use case biểu diễn một tính năng được yêu cầu nào đó và biến thể của nó
• Quan hệ giữa tác nhân và use case hay giữa các use case (được biểu diễn bằng các đường hay đường nét đứt)

CHƯƠNG 10: TÀI LIỆU THIẾT KẾ

- 7 vai trò của tài liệu thiết kế

• 1.Cho người quản lí: biết các thành phần, chức năng -> ước lượng chi phí
• 2.Người quản lí cấu hình: thông tin về ráp nối các thành phần và kiểm soát thay đổi
• 3.Người thiết kế: chức năng và thành phần của hệ thống, quan hệ giữa các thành phần
• 4.Programmer: giải thuật, CTDL, tương tác giữa các thành phần
• 5. Người kiểm tra đơn vị (unit tester): thông tin về thành phần, giải thuật được dùng và dữ liệu cần thiết
• 6.Người kiểm tra tích hợp: quan hệ giữa các thành phần, chức năng và các thành phần có liên quan
• 7.Người lập trình bảo trì: các thành phần, cách hiện thức hóa các yêu cầu người dùng

- 10 thuộc tính của tài liệu thiết kế

• 1.Định danh: tên
• 2.Kiểu: kiểu của thành phần
• 3.Mục đích
• 4.Chức năng
• 5.Hỗ trợ: thực thể hợp thành từ những thành phần nào
• 6.Phụ thuộc
• 7.Giao diện: với thành phần khác
• 8.Nguồn lực cần thiết
• 9. Xử lí: giải thuật, khởi tạo, quản lí
• 10.Dữ liệu: mô tả, formart, ý nghĩa

CHƯƠNG 11: LẬP TRÌNH

- Cấu trúc điều khiển: Làm cho mã lệnh dễ đọc; Xây dựng chương trình từ các khối mô đun; Không làm cho mã lệnh quá cụ thể; Sử dụng các tên tham số và các chú thích để biểu thị sự kết hợp giữa các thành phần; Làm cho sự phụ thuộc giữa các thành phần rõ ràng

- Viết lại:

if (age < 55) benefit = minimum;

elseif (AGE < 65) benefit = minimum * 1.5;

elseif (AGE < 75) benefit = minimum * 1.5 + bonus;

else benefit = maximum;

- Bốn đặc trưng then chốt để kiểm tra thành phần tái sử dụng

• Thành phần có thực hiện chức năng hay cung cấp dữ liệu được cần hay không?
• Cần ít sự sửa đổi thành phần hơn so với xây dựng thành phần từ đầu?
• Thành phần có được dẫn chứng bằng tài liệu rõ ràng?
• Có hồ sơ hoàn chỉnh cho lịch sử xem lại và kiểm thử thành phần?

- Tài liệu nội: Khối chú thích ở phần đầu;  Các nhãn câu lệnh và các tên biến có nghĩa; Các chú thích khác; Định dạng để gia tăng sự hiểu biết; Dẫn chứng bằng tài liệu cho dữ liệu (từ điển dữ liệu);

- Tài liệu ngoại: Mô tả vấn đề; Mô tả giải thuật; Mô tả dữ liệu

- Quy trình lập trình:

• Lập trình theo cách giải quyết vấn đề: Bốn giai đoạn phân biệt để tìm ra giải pháp hoàn thiện: Hiểu vấn đề; Lập kế hoạch; Thực hiện kế hoạch; Xem lại
• Lập trình extreme: Hai kiểu tham gia
  • Khách hàng: người định nghĩa các đặc điểm bằng cách sử dụng các tình tiết, mô tả các kiểm thử chi tiết và gán các ưu tiên
  • Lập trình viên: người thực thi các tình tiết
• Lập trình theo cặp: Vai trò của từng lập trình viên theo cặp
  • Driver hay pilot: điều khiển máy tính và viết mã lệnh
  • Navigator: xem lại các mã lệnh của driver và đưa ra thông tin phản hồi

CHƯƠNG 12: KIỂM THỬ

- Các nguyên nhân làm phần mềm không hoạt động:  Đặc tả sai; Đặc tả thiếu; Yêu cầu không thể thực thi; Thiết kế không chính xác;  Mã lệnh có thiếu sóy

- Tổ chức kiểm thử: Kiểm thử mô đun, kiểm thử thành phần hay kiểm thử đơn vị; Kiểm thử tích hợp; Kiểm thử chức năng; Kiểm thử sự thực hiện; Kiểm thử sự thực hiện; Kiểm thử chấp nhận; Kiểm thử cài đặt

- Các bước kiểm thử đơn vị

• Xem lại mã lệnh
• Biên dịch mã lệnh và loại bỏ bất cứ lỗi cú pháp nào còn lại
• Phát triển các trường hợp kiểm thử để chỉ ra rằng input được chuyển đổi chính xác thành ouput mong đợi