Tư luận - bài tập tự luận học máy |Đại học Xây Dựng Hà Nội
Câu 1 : Trình bày hiểu biết của em về quy trinh kỹ nghệ yêu cầu1. Nghiên cứu khả thi (Feasibility study):Một nghiên cứu ngắn, tập trung, nhằm kiểm tra xem – Hệ thống có đóng góp cho các mục tiêu của tổ chức hay không? – Hệ thống có thể được phát triển bằng công nghệ hiện hành và trong phạm vi ngân sách hay không? – Hệ thống có thể được tích hợp với các hệ thống khác đang được sử dụng hay không?Tài liệu giúp bạn tham khảo,ôn tập và đạt kết quả cao.Mời bạn đón xem
Môn: công nghệ thông tin(HUCE)
Trường: Đại học Xây Dựng Hà Nội
Thông tin:
Tác giả:
Preview text:
lOMoARcPSD| 45222017
Câu 1 : Trình bày hiểu biết của em về quy trinh kỹ nghệ yêu cầu
1. Nghiên cứu khả thi (Feasibility study): -
Một nghiên cứu ngắn, tập trung, nhằm kiểm tra xem – Hệ thống có đóng góp cho các mục
tiêu của tổ chức hay không? – Hệ thống có thể được phát triển bằng công nghệ hiện hành và
trong phạm vi ngân sách hay không? – Hệ thống có thể được tích hợp với các hệ thống khác
đang được sử dụng hay không? 2. Thu thập yêu cầu: -
Kỹ sư phần mềm làm việc với các stakeholder để tìm ra " Miền ứng dụng ". • Các vấn đề của
thu thập yêu cầu phần mềm: – Phạm vi của phần mềm (Scope) – Hiểu rõ phần mềm
(Understanding) – Các thay đổi của hệ thống (Volatillity) -
Phương pháp phát hiện yêu cầu phần mềm (Requirements Elicitation Methodology) – Xác
định các phương pháp sử dụng phát hiện các yêu cầu phần mềm: phỏng vấn (closed
interviews và open interviews) bảng điều tra câu hỏi, làm việc nhóm, các buổi họp, gặp gỡ
đối tác, v.v. – Tìm kiếm các nhân sự (chuyên gia, người sử dụng) – Tự quan sát các quy trình nghiệp vụ -
Bao gồm các giai đoạn: –Phát hiện yêu cầu. –Phân loại các yêu cầu phần mềm và tổ chức
chúng theo các nhóm liên quan. (3) Chính là phân tich yêu cầu – Đàm phán, thương lượng
và đánh thứ tự ưu tiên. (3) Chính là phân tich yêu cầu và thương lượng –Kết quả là bản đặc
tả yêu cầu(4). Chi tiết hơn về bản đặc tả yêu cầu chúng ta sẽ tìm hiểu sau -
Sản phẩm của việc phát hiện yêu cầu phần mềm: – Bảng kê (statement) các đòi hỏi và chức
năng khả thi của phần mềm – Bảng kê phạm vi ứng dụng của phần mềm – Mô tả môi trường
kỹ thuật của phần mềm – Bảng kê tập hợp các kịch bản sử dụng của phần mềm – Các
nguyên mẫu xây dựng, phát triển hay sử dụng trong phần mềm (nếu có) – Danh sách nhân
sự tham gia vào quá trình phát hiện các yêu cầu phần mềm - kể cả các nhân sự từ phía công ty- khách hàng
3. . Phân tich yêu cầu và thương lượng: -
Phân loại các yêu cầu phần mềm và sắp xếp chúng theo các nhóm liên quan. -
Khảo sát tỉ mỉ từng yêu cầu phần mềm trong mối quan hệ của nó với các yêu cầu phần mềm khác. -
Phân cấp các yêu cầu phần mềm theo dựa trên nhu cầu và đòi hỏi khách hàng / người sử dụng -
Phân tich các rủi ro có thể xảy ra với từng yêu cầu phần mềm. -
Đánh giá thô về giá thành và thời gian thực hiện của từng yêu cầu phần mềm trong giá
thành sản phẩm phần mềm và thời gian thực hiện phần mềm -
Giải quyết tất cả các bất đồng về yêu cầu phần mềm với khách hàng trên cơ sở thảo luận và
thương lượng các yêu cầu đề ra
4. Đặc tả yêu cầu phần mềm: -
Các khía cạnh phải đặc tả trong phát triển phần mềm: – Đặc tả vận hành chức năng
(Operational spectifications) mô tả các hoạt động của hệ thống phần mềm sẽ xây dựng. –
Đặc tả mô tả/phi chức năng (Descriptive specifications) – đặc tả các đặc tinh đặc trưng của
phần mềm: Định nghĩa các tinh chất của hệ thống, các ràng buộc, thí dụ như độ tin cậy, thời lOMoARcPSD| 45222017
gian trả lời, dung lượng bộ nhớ,…Các yêu cầu do tổ chức qui định như qui định chuẩn về quá
trình tiến hành, chuẩn tài liệu
5. Mô hình hóa yêu cầu hệ thống: -
Phải ước định được các thành phần của hệ thống trong mối quan hệ với nhau để xác định
được yêu cầu như thế nào thì phù hợp với phần mềm và để đánh giá được mức chuyên
nghiệp của hệ thống khi được hoàn thành -
Use case: Là một dạng mô tả kịch bản trong UML. Một tập use case mô tả tất cả các tương
tác có thể có với hệ thống. Ví dụ: Hệ thống đăng ký khám bệnh
6. Thẩm định yêu cầu (Requirements Validation) : -
Xem xét lại yêu cầu: • Phân tich một cách có hệ thống • Lấy ý kiến khách hàng • Tiến hành thường xuyên -
Làm bản mẫu: – Sử dụng mô hình khả dụng – Kiểm tra tinh thực hiện được -
Tạo ca kiểm thử (test case): kiểm tra tinh kiểm tra được Sử dụng CASE: để kiểm tra tinh nhất quán 7. Quản trị yêu cầu -
Quản trị yêu cầu (requirements management) là quy trình quản trị sự thay đổi yêu cầu trong
suốt quá trình kỹ nghệ yêu cầu và phát triển hệ thống
• Các yêu cầu mới phát sinh khi hệ thống đang được phát triển và cả khi nó được đưa vào sử dụng
• Cần theo dõi những yêu cầu đơn lẻ và duy trì mối liên hệ giữa các yêu cầu phụ thuộc
nhau để có thể đánh giá được ảnh hưởng khi thay đổi yêu cầu.
• Cần thiết lập một quy trình hình thức cho những đề nghị thay đổi và tạo mối liên hệ
giữa yêu cầu này với các yêu cầu hệ thống - Nguyên nhân thay đổi yêu cầu :
• Môi trường kinh doanh và công nghệ của hệ thống luôn thay đổi sau khi cài đặt xong phần mềm.
• Những người trả tiền cho hệ thống thường ít khi là những người dùng cuối của phần
mềm. Do đó trong quá trình sử dụng có thể phát sinh ra các tinh năng mới cần được
thêm vào hệ thống để hỗ trợ người dùng
• Các hệ thống lớn thường có một cộng đồng người dùng đa dạng. Do vậy không
tránh khỏi việc những người dùng này có yêu cầu và sự ưu tiên khác nhau có thể
gây xung đột hoặc mâu thuẫn nên cần thỏa hiệp giữa họ. Và để cân bằng việc hỗ trợ
các khách hàng khác nhau thì theo kinh nghiệm thường phải thay đổi yêu cầu phần mềm hệ thống -
Quy tắc quản trị yêu cầu: – Mỗi yêu cầu phải là duy nhất. – Quá trình quản trị thay đổi là tập
hợp của các hoạt động đánh giá tác động và chi phí thay đổi. – Chính sách truy đến yêu cầu:
Phải có chính sách xác định mối quan hệ giữa mỗi yêu cầu và giữa các yêu cầu. – Phải có
công cụ hỗ trợ quản trị yêu cầu.
Câu 2: em hay liet ke cac pha va quan diem ve cac pha ve quy trinh phat trien phan mem (quy trinh ky nghe phat trien phan mem)
Quy trình phát triển phần mềm (Software Development Life Cycle - SDLC) là một quy trình hệ thống để
phát triển phần mềm từ giai đoạn khởi đầu đến giai đoạn hoàn thành. Dưới đây là một số pha và quan
điểm phổ biến trong quy trình phát triển phần mềm:
1. Phân tich yêu cầu (Requirement Analysis): lOMoARcPSD| 45222017 •
Pha này tập trung vào việc thu thập và phân tich yêu cầu của khách hàng. •
Mục tiêu là hiểu rõ nhu cầu và mong đợi của khách hàng để xác định phạm vi dự án. 2. Thiết kế (Design): •
Trong pha này, các nhà phát triển thiết kế kiến trúc và cấu trúc của hệ thống. •
Được chia thành thiết kế cấp cao (high-level design) và thiết kế cấp thấp (low-level
design) để đảm bảo rằng các yêu cầu được chia nhỏ và dễ triển khai. 3. Lập trình : •
Pha này tập trung vào việc viết mã và triển khai hệ thống. •
Nhà phát triển sử dụng các ngôn ngữ lập trình và công cụ phát triển để tạo ra phần
mềm theo yêu cầu đã xác định. 4. Kiểm thử (Testing): •
Trước khi phần mềm được triển khai, nó cần được kiểm tra để đảm bảo tinh đúng đắn
và hoạt động như mong đợi. •
Kiểm thử có thể bao gồm kiểm thử đơn vị, kiểm thử tich hợp, kiểm thử hệ thống và kiểm thử chấp nhận.
5. Triển khai và bảo trì (Deployment and Maintenance): •
Sau khi phần mềm đã được kiểm thử và chấp nhận, nó sẽ được triển khai cho người dùng cuối. •
Các hoạt động bảo trì sẽ được thực hiện để duy trì và nâng cấp phần mềm theo yêu cầu mới.
Có nhiều quan điểm và pha khác nhau về quy trình phát triển phần mềm, và các pha có thể được tùy
chỉnh để phù hợp với dự án cụ thể. Một số quan điểm khác bao gồm: •
Agile: Mô hình phát triển linh hoạt, tập trung vào việc phân chia dự án thành các pha
ngắn gọn (sprints) và tăng cường sự tương tác và phản hồi của khách hàng. •
Waterfall: Mô hình phát triển tuần tự, trong đó các pha diễn ra theo trình tự tuyến tinh và không quay lại. •
Spiral: Mô hình kết hợp giữa phương pháp tuần tự và linh hoạt, với việc lặp lại các pha
để kiểm tra và đánh giá rủi ro trước khi tiến xa hơn. •
DevOps: Kết hợp quy trình phát triển phần mềm với hoạt động vận hành hệ thống để
tạo ra một quy trình liên tục và tự động hóa.
Quy trình phát triển phần mềm có thể khác nhau tùy thuộc vào dự án, công ty và ngữ cảnh.
Câu 3: trình bày hiểu biết của em về 1 só kỹ thuật kiểm thử hướng đối tượng , từ đó hãy so sánh kiểm
thử đơn vị và kiểm thử thành phần lOMoARcPSD| 45222017
Kỹ thuật kiểm thử hướng đối tượng (Object-Oriented Testing) là một phương pháp kiểm thử phần mềm
tập trung vào việc kiểm tra các đối tượng và quan hệ giữa chúng trong hệ thống phần mềm hướng đối
tượng. Dưới đây là trình bày về hiểu biết của tôi về kỹ thuật kiểm thử hướng đối tượng và sự khác biệt
giữa kiểm thử đơn vị và kiểm thử thành phần:
1. Kỹ thuật kiểm thử hướng đối tượng: •
Kỹ thuật kiểm thử hướng đối tượng tập trung vào việc kiểm tra các đối tượng, phương
thức và tương tác giữa chúng trong hệ thống phần mềm hướng đối tượng. •
Nó sử dụng các kỹ thuật như kiểm thử đơn vị, kiểm thử tich hợp và kiểm thử hộp trắng
để đảm bảo rằng các đối tượng và quan hệ giữa chúng hoạt động đúng và tuân thủ các
nguyên tắc hướng đối tượng. 2. Kiểm thử đơn vị: •
Kiểm thử đơn vị là quá trình kiểm thử các thành phần nhỏ nhất trong phần mềm, chẳng
hạn như lớp, phương thức hoặc đối tượng riêng lẻ. •
Nó tập trung vào việc xác định lỗi và kiểm tra tinh đúng đắn của các đơn vị phần mềm. •
Các kỹ thuật kiểm thử đơn vị bao gồm kiểm thử hộp đen (black-box testing) và kiểm thử
hộp trắng (white-box testing).
3. Kiểm thử thành phần: •
Kiểm thử thành phần tập trung vào việc kiểm tra tinh tương tác và tinh hoạt động của
các thành phần phần mềm khi được kết hợp với nhau. •
Thành phần có thể là một tập hợp các đối tượng, lớp hoặc module phần mềm. •
Các kỹ thuật kiểm thử thành phần bao gồm kiểm thử tich hợp, kiểm thử giao diện và kiểm thử hệ thống.
So sánh giữa kiểm thử đơn vị và kiểm thử thành phần: •
Phạm vi: Kiểm thử đơn vị tập trung vào các thành phần nhỏ nhất trong phần mềm,
trong khi kiểm thử thành phần tập trung vào tinh tương tác giữa các thành phần khi chúng được kết hợp. •
Đơn vị kiểm thử: Kiểm thử đơn vị kiểm tra từng đơn vị phần mềm riêng lẻ, trong khi
kiểm thử thành phần kiểm tra các thành phần được kết hợp với nhau. •
Mục tiêu: Kiểm thử đơn vị tập trung vào xác định lỗi và đảm bảo tinh đúng đắn của từng
đơn vị, trong khi kiểm thử thành phần tập trung vào kiểm tra tinh tương tác và tinh hoạt
động của các thành phần khi chúng được kết hợp. •
Phụ thuộc: Kiểm thử thành phần phụ thuộc vào kiểm thử đơn vị để đảm bảo tinh đúng
đắn của từng thành phần riêng lẻ trước khi kiểm tra tinh tương tác giữa chúng.
Câu 4: trình bày hiểu biết của em về mô hình lập trình. liệt kê một số mô hinh lập trình phổ biến và minh họa lOMoARcPSD| 45222017 -
Mô hình lập trình là một cách phân loại ngôn ngữ lập trình dựa trên tinh năng của chúng. -
Một ngôn ngữ có thể hỗ trợ nhiều mô hình lập trình. -
Một số mô hình chủ yếu quan tâm đến sự thực thi của chương trình, các mô hình khác lại
chủ yếu quan tâm đến cách tổ chức mã code, tuy nhiên những mô hình khác lại chỉ quan
tâm đến phong cách của cú pháp và ngữ pháp. -
Các mô hình lập trình phổ biến bao gồm:
• Lập trình mệnh lệnh: Là mẫu hình lập trình sử dụng một chuỗi các câu lệnh để thay đổi trạng thái của chương trình. Bao gồm như:
– Lập trình hướng thủ tục thực hiện nhóm các câu lệnh trong các thủ tục/các hàm. – Lập
trình hướng đối tượng thực hiện code để tạo ra các đối tượng trừu tượng hóa các đối
tượng trong bài toán thực tế.
• Lập trình khai báo: Trong đó các lập trình viên khai báo các thuộc tinh của kết quả mong
muốn,nhưng không thực hiện tinh toán nó.
Lập trình khai báo bao gồm như:
• Lập trình hướng chức năng: Kết quả mong muốn được khai báo như dãy giá trị của chức năng các ứng dụng.
• Lập trình logic: Dựa trên logic toán trong các mối quan hệ và các suy luận.
• Lập trình tinh toán: Trong đó kết quả mong muốn được khai báo là giải pháp của một bài toán tối ưu.
• Lập trình phản ứng(reactive): Trong đó kết quả mong muốn được khai báo với các luồng dữ
liệu và sự lan truyền của sự thay đổi
Ví dụ: Duyệt danh sách đưa ra số chẵn
– Lập trình mệnh lệnh: - Lập trình khai báo :
1. Mô hình lập trình hướng thủ tục (Procedural Programming): •
Mô hình lập trình hướng thủ tục tập trung vào việc xây dựng các thuật toán và quy trình thực hiện. •
Các chương trình được chia thành các hàm hoặc thủ tục, và các biến được sử dụng để lưu trữ dữ liệu. •
Ví dụ ngôn ngữ lập trình hướng thủ tục: C, Pascal. lOMoARcPSD| 45222017
2. Mô hình lập trình hướng đối tượng (Object-Oriented Programming): •
Mô hình lập trình hướng đối tượng tập trung vào việc xây dựng các đối tượng, quan hệ và phương thức. •
Các đối tượng là các thực thể có thuộc tinh và hành vi riêng, và chúng tương tác thông
qua cơ chế kế thừa, đa hình và đóng gói. •
Ví dụ ngôn ngữ lập trình hướng đối tượng: Java, C++, Python.
3. Mô hình lập trình hướng sự kiện (Event-Driven Programming): •
Mô hình lập trình hướng sự kiện tập trung vào xử lý các sự kiện và phản ứng tương ứng. •
Chương trình được thiết kế để phản ứng và xử lý các sự kiện từ nguồn bên ngoài, chẳng
hạn như nút nhấn, chuột hoặc bàn phím. •
Ví dụ ngôn ngữ lập trình hướng sự kiện: JavaScript, Visual Basic.
4. Mô hình lập trình hướng logic (Logic Programming): •
Mô hình lập trình hướng logic tập trung vào việc mô tả các ràng buộc và quy tắc logic. •
Chương trình được xây dựng dựa trên việc xác định các luật logic và các mệnh đề để giải quyết vấn đề. •
Ví dụ ngôn ngữ lập trình hướng logic: Prolog.
5. Mô hình lập trình hướng dịch vụ (Service-Oriented Programming): •
Mô hình lập trình hướng dịch vụ tập trung vào việc xây dựng các dịch vụ độc lập và kết
hợp chúng để tạo ra ứng dụng. •
Các dịch vụ được xác định bởi giao diện và có thể được truy cập và sử dụng bởi các ứng dụng khác. •
Ví dụ ngôn ngữ lập trình hướng dịch vụ: Web services (SOAP, REST).
Mỗi mô hình lập trình có ưu điểm và hạn chế riêng, và lựa chọn mô hình phù hợp phụ thuộc vào yêu cầu
và tinh chất của dự án phát triển phần mềm. Ngoài những mô hình lập trình được liệt kê ở trên, còn có
nhiều mô hình khác như Mô hình lập trình logic (Logic Programming), mô hình lập trình hướng khai thác
dữ liệu (Data-Driven Programming), mô hình lập trình hướng hợp đồng (Contract-Based Programming),
mô hình lập trình hướng khai phá (Exploratory Programming), và nhiều mô hình khác nữa. Sự lựa chọn
mô hình lập trình phù hợp phụ thuộc vào bối cảnh và mục tiêu của dự án.