Chương 1 : Giới thiệu về Công Nghệ Phần Mềm

1. 4 đặc tính của phần mềm tốt

- Bảo trì được : Phần mềm cần được viết theo cách này để nó có khả năng đáp ứng tốt các nhu cầu của khách hàng.

- An toàn và tin cậy : Trong trường hợp hệ thống bị lỗi, phần mềm phải không được gây thiệt hại đến vật chất hoặc kinh tế.

- Hiệu quả : Phần mềm không làm lãng phí tài nguyên hệ thống như bộ nhớ hoặc bộ vi xử lý.

- Chấp nhận được : Dễ hiểu, dễ sử dụng và tương thích với các hệ thống khác mà người dùng đang sử dụng.

2. Vẽ hình và giải thích sự thoái hóa của phần mềm

3. So sánh quy trình, ưu, nhược điểm của mô hình thác nước và mô hình tiến hóa

Sơ đồ mô hình thác nước

http://gg.gg/thacnuoc

Sơ đồ mô hình tiến hóa

http://gg.gg/tienhoa

*** Mô hình thác nước vs Mô hình tiến hóa ***

Ưu điểm

Mô hình thác nước

Dễ quản lý

Thời gian hoàn thành dự án thường được dự báo với độ chính xác hơn so với các mô hình khác

Mô hình tiến hóa

Cho phép khách hàng tham gia sâu hơn vào quá trình phát triển, nhờ đó sản phẩm cuối cùng thường phản ánh chính xác mong muốn của khách hàng.

Nhược điểm

Mô hình thác nước

Mô hình đòi hòi một bản yêu cầu (requirement) đầy đủ và chính xác từ phía khách hàng

Khách hàng cần phải kiên nhẫn

Mô hình tiến hóa

Khó khăn trong việc thiết kế.

Khó khăn trong việc quản lí.

Khó khăn do khách hàng gây ra.

Khó khăn về địa lý.

4. Trình bày quy trình, ưu, nhược điểm của mô hình phát triển tăng dần

http://gg.gg/phattrientangdan

- Ưu điểm :

Các đợt đầu đóng vai trò phiên bản thử nghiệm (prototype) để hỗ trợ việc làm rõ bộ yêu cầu cho các đợt sau.

Rủi ro thấp đối với thất bại toàn bộ dự án.

Các dịch vụ hệ thống có ưu tiên cao nhất có xu hướng được kiểm thử nhiều nhất.

- Nhược điểm :

Không phải dự án nào cũng có thể được phân chia thành các phần tăng trưởng nhỏ có thể được phát triển và bàn giao tuần tự. Nếu làm không tốt giai đoạn lập kế hoạch và phân tách hệ thống, xung đột giữa các thành phần có thể nảy sinh.

5. Những nguyên lý cơ bản của Agile

Nguyên tắc

Mô tả

Tham gia của khách hàng

Khách hàng tham gia quá trình phát triển, nhiệm vụ cung cấp và đặt độ ưu tiên cho các yêu cầu, thẩm định hệ thống sau từng lần lặp.

Bàn giao tăng dần

Phần mềm được phát triển theo từng đợt, khách hàng xác định những yêu cầu cần hoàn thành trong từng đợt.

Con người không phải là quy trình

Kỹ năng của đội phát triển cần được ghi nhận và khai thác. Thành viên cần được cho phép làm việc theo cách riêng không theo qui trình xác định trước.

Tính đến thay đổi

Xác định trước là yêu cầu sẽ có lúc thay đổi, do đó thiết kế hệ thống để có thể thích ứng với những thay đổi này.

Duy trì sự đơn giản

Tập trung vào sự đơn giản của phần mềm lẫn qui trình phát triển phần mềm. Bất cứ khi nào có thể, chủ động loại bỏ những sự phức tạp khỏi hệ thống.

6.       Nêu những vấn đề cần xem xét để quyết định chọn phát triển hướng kế hoạch hay Agile

-          Hệ được phát triển thuộc loại nào?

-          Hệ có khả năng bị kiểm duyệt từ bên ngoài?

-          Vòng đời của hệ?

-          Hệ được phát triển lớn hay nhỏ?

-          Đội phát triển được tổ chức thế nào?

-          Khả năng của người thiết kế và lập trình viên đến đâu?

-          Có sẵn những công nghệ nào để hỗ trợ phát triển?

-          Có cần phải có đặc tả và thiết kế chi tiết trước khi cài đặt ko?

-          Chiến thuật bàn giao tăng dần có khả thi không?

-          Có vấn đề về văn hóa hay tổ chức nào có thể ảnh hưởng đến việc phát triển không?

7.       Nêu những nguyên lý thực hành của Extreme Programming

Nguyên lý

Mô tả

Lập lịch tăng dần

Yêu cầu được ghi trên story card, được phân vào từng đợt release dựa trên thời gian hoàn thành và độ ưu tiên. Người phát triển phân các stories này thành các “nhiệm vụ”.

Bàn giao nhỏ

Tập tối thiểu các chức năng hữu dụng được bàn giao trước. Bàn giao được thự hiện đều đặn và thêm dần chức năng vào phiên bản đầu tiên.

Thiết kế đơn giản

Thiết kế vừa đủ đáp ứng yêu cầu người dùng và không hơn.

Test-first development

Frame work để test unit tự động hóa được dùng để viết test cho chức năng mới trước khi chức năng đó được cài đặt.

Refactoring

Mọi lập trình viên đều nên refractor liên tục mỗi khi thấy có thể cải tiến được mã. Điều này giúp mã đơn giản, dễ bảo trì

Chương 4 : Yêu Cầu

8.       Phân tích tại sao cần phải có 2 bản tài liệu yêu cầu hệ thống và người dùng?

-          Vì hướng đến người đọc khác nhau.

-          Yêu cầu người dùng trước tiên cần sử dụng để mời thầu các công ty phần mềm, vậy nên phải dành chỗ cho từng công ty phát triển giải pháp riêng để đấu thầu, vì thế cần có 2 bản tài liệu yêu cầu hệ thống và người dùng.

-          Yêu cầu người dùng cũng để người dùng đọc, cần có 2 bản tài liệu yêu cầu hệ thống và người dùng.

-          Yêu cầu hệ thống xác định một giải pháp cụ thể, để người phát triển đọc, cần có 2 bản tài liệu yêu cầu hệ thống và người dùng.

9.       Xác định và mô tả ngắn gọn 4 loại yêu cầu có thể được định nghĩa cho một phần mềm.

-          Yêu cầu người dùng : Các phát biểu bằng ngôn ngữ tự nhiên cộng với các sơ đồ về các dịch vụ mà hệ thống cung cấp và các ràng buộc về vận hành. Được viết cho khách hàng.

-          Yêu cầu hệ thống : Một tài liệu có cấu trúc bao gồm các mô tả chi tiết về các chức năng và dịch vụ của hệ thống cùng với các ràng buộc về vận hành. Định nghĩa cái gì cần được cài đặt.

-          Yêu cầu chức năng : Phát biểu về các dịch vụ mà hệ thống cần cung cấp.

-          Yêu cầu phi chức năng : Ràng buộc về các dịch vụ hay chức năng của hệ thống.

5.       Nêu các loại biểu đồ UML cơ bản, giải thích ý nghĩa

-          Biểu đồ ngữ cảnh

-          User case

-          Tuần tự

-          Hoạt động

-          Lớp

-          Trạng thái