Câu 1: Phần mềm là gì? Các đặc điểm của phần mềm?

v Phần mềm là gì:

“Phần mềm là một tập hợp bao gồm:

- Các lệnh (chuong trình máy tính) khi thực hịên thì dua ra hoạt dộng và kết quả

mong muốn.

- Các cấu trúc dữ liệu làm cho chuong trình thao tác thông tin thích hợp.

- Các tài liệu mô tả thao tác và cách dùng chuong trình

v Các điểm của phần mềm:

Phần mềm là phần tử của hệ thống logic chua không phải hệ thống vật lý. Do vậy, phần mềm có một số dặc trung khác biệt dáng kể dối với dặc trung của phần cứng.

· Ðặc trung 1: Phần mềm duợc phát triển hay duợc kỹ nghệ hoá, nó không duợc chế tạo theo nghia cổ diển.

Mặc dầu có một số điểm tương đồng giữa phát triển phần mềm và chế tạo phần cứng, hai hoạt dộng này về co bản là khác nhau. Trong cả hai hoạt dộng này, chất luợng cao duợc dạt tới thông qua thiết kế tốt, nhung giai doạn chế tạo phần cứng có thể dua vào vấn dề mà chất luợng không tồn tại (hay dễ duợc sửa dổi) cho phần mềm. Cả hai hoạt dộng này dều phụ thuộc vào con nguời, nhung mối quan hệ giữa nguời duợc áp dụng và công việc duợc thực hiện hoàn toàn khác. Cả hai hoạt dộng này dòi hỏi việc xây dựng "sản phẩm", nhung cách tiếp cận là hoàn toàn khác. Phần mềm duợc chế tạo ra là hoàn toàn mới, không có tiền lệ truớc và nó cung chỉ duợc tạo ra 1 lần duy nhất.

· Ðặc trung 2: Phần mềm không “hỏng di”.

Phần mềm không cảm ứng với khiếm khuyết môi truờng vốn gây cho phần cứng mòn cu di. Phần mềm nếu cứ với các bộ dữ liệu dầu vào hợp lý thì nó luôn cho kết quả có ý nghia giống nhau, không thay dổi theo thời gian, diều kiện khí hậu, …

Thực tế, phần mềm sẽ trải qua sự thay dổi (bảo trì). Khi thay dổi duợc thực hiện, có thể một số khiếm khuyết sẽ duợc thêm vào, gây ra trong duờng cong tỷ lệ hỏng có dấu hiệu nhu hình vẽ duới dây. Truớc khi duờng cong dó có thể trở về tỷ lệ hỏng hóc ổn dịnh ban dầu, thì một yêu cầu khác lại duợc dua vào, lại gây ra duờng cong phát sinh dỉnh nhọn một lần nữa. Dần dần, mức tỷ lệ hỏng tối thiểu tang lên - phần mềm bị thoái hoá do sự thay dổi.

Nhận xét: Phần cứng hỏng có “vật tu thay thế”, nhung không có phần mềm thay thế cho phần mềm. Mọi hỏng hóc của phần mềm dều chỉ ra lỗi trong thiết kế hay trong tiến trình chuyển thiết kế thành mã hoá lệnh máy thực hiện duợc. Do dó, việc bảo trì phần mềm bao gồm việc phụ thêm dáng kể so với bảo trì phần cứng.

· Ðặc trung 3: Phần lớn phần mềm duợc xây dựng theo don dặt hàng, chứ ít khi duợc lắp ráp từ các thành phần có sẵn.

vẽ sơ đồ mạch số => thực hiện phân tích dể dảm bảo chức năng đúng => phân loại các danh mục thành phần => gắn cho mỗi mạch tích hợp (thuờng gọi là IC hay chip) một số hiệu một chức nang dã dịnh truớc và hợp lệ; một giao diện dã xác dịnh rõ; một tập các huớng dẫn tích hợp chuẩn hoá.

Ðối với phần mềm: Khi xây dựng ta không có danh mục các thành phần. Phần mềm duợc dặt hàng với don vị hoàn chỉnh, không phải là những thành phần có thể lắp ráp lại thành chuong trình mới

Câu 11: Kiểm thử phần mềm là gì? Phân biệt các khái niệm: Error, Bug, Failure, Incident, Test case?

1.Kiểm thử phần mềm: là quá trình thực hiên một chương trình với mục đích tìm ra tất cả các lỗi có thể

Nguyên tắc kiểm thử (Testing principles):

-Kiểm thử không phải là gỡ rối (Debugging)

-Kiểm thử không bao giờ có thể phát hiện hoàn toàn 100% lỗi

-Mục đích của kiểm thử là tìm ra lỗi chứ không phải nguyên nhân gây ra chúng

Error -Là lỗi do con người gây ra, còn gọi là mistake,

Bug - Khi lập trình viên gây ra lỗi trong quá trình viết mã

Failure Là lỗi xuất hiện khi một lỗi do người gây ra được thực thi, thường là lỗi do mã nguồn

Incident Là “Failure” mà khi xảy ra nó được nhận biết bởi người dùng bằng những biểu hiện của nó

Test Case

-Test la qua trình thực hiện tìm ra Failure hoặc chứng tỏ sự thực hiện là đúng.

-Tạm dịch là các trường hợp kiểm thử. Khi một trường hợp được kiểm thử là tương ứng với một lần thực hiện chương trình với một dữ liệu vào và tập dữ liệu ra mong muốn. Từ đó ta có thể phát hiện ra chương trình có các Failure hay không khi kết quả ra thực sự không như kết quả ra mong muốn.

câu 5: Trình bày các mô hình pt phần mềm: Thác nước, Phát triển nhanh, Tăng trưởng, Xoắn ốc?

Ø Phân tích yêu cầu:

-Để hiểu về hệ thống và các yêu cầu về chức năng, hiệu suất, giao diện

-Kết quả của bước phân tích yêu cầu được trình bày bằng tài liệu và được kiểm duyệt bởi khách hàng.

Ø Thiết kế:

-Tập trung vào cấu trúc dữ liệu, kiến trúc hệ thống, giao diện và thuật toán

-Tiến trình thiết kế dịch các yêu cầu thành một biểu diễn của phần mềm có thể được định giá về chất lượng trước khi giai đoạn mã hoá bắt đầu.

-Kết quả của bước thiết kế được thể hiện bằng tài liệu

Ø Viết mã:

-Chuyển sự thiết kế sang chương trình máy tính

Ø Kiểm thử:

-Tập trung vào các yếu tố logic trong phần mềm, đảm bảo kiểm tra lại cấu trúc dòng mã, các chức năng của phần mềm

-Kiểm tra lại rằng với dữ liệu vào xác định thì sẽ thu được kết quả ra phù hợp với yêu cầu.

Ø Vận hành và bảo trì: Phần mềm chắc chắn sẽ phải trải qua những thay đổi sau khi nó được bàn giao cho khách hàng (một ngoại lệ có thể là những phần mềm nhúng). Thay đổi sẽ xuất hiện bởi vì gặp phải lỗi, bởi vì phần mềm phải thích ứng với những thay đổi trong môi trường bên ngoài (chẳng hạn như sự thay đổi do hệ điều hành mới hay thiết bị ngoại vi mới), hay bởi vì khách hàng yêu cầu nâng cao chức năng hay hiệu năng. Việc bảo trì phần mềm phải áp dụng lại các bước vòng đời nói trên cho chương trình hiện tại chứ không phải chương trình mới.

v Ưu điểm:

Các giai đoạn được định nghĩa, với đầu vào và đầu ra rõ ràng. Mô hình này cơ bản dựa trên tài liệu nhất là trong các giai đoạn đầu, đầu vào và đầu ra đều là tài liệu.Sản phẩm phần mềm được hình thành thông qua chuỗi các hoạt động xây dựng phần mềm theo trình tự rõ ràng.

v Nhược điểm:

Đòi hỏi tất cả yêu cầu phần mềm phải được xác định rõ ràng ngay từ đầu dự án. Nhưng đa số dự án thực tế cho thấy yêu cầu phần mềm thường ẩn chứa không nhiều thì ít những điểm không chắc chắn.

Một thực tế là các dự án hiếm khi được thực hiện đầy đủ các bước trong suốt chu kỳ dự án. Đặc biệt là giai đoạn kiểm thử khi gần đến ngày giao hàng chẳng hạn, nếu có trục trặc xảy ra do yêu cầu phần mềm không rõ ràng hay thiết kế có lỗi, xu hướng là mã nguồn được sửa đổi trực tiếp mà không qua các bước bổ sung theo đúng mô hình, nên dẫn đến bản đặc tả phần mềm cũng như một số sản phẩm trung gian khác như bản thiết kế, cho dù có được cập nhật sau này cũng có thể không phản ánh đầy đủ những gì đã được sửa đổi trong mã nguồn.

Người sử dụng không có cơ hội tham gia trong suốt thời gian của các giai đoạn trung gian từ thiết kế cho đến kiểm thử. Đặc biệt với những dự án lớn, người sử dụng chỉ có thể nhận ra rằng hệ thống phần mềm không phù hợp cho nhu cầu của họ vào thời điểm cuối dự án.

Nói chung, mô hình này thường ẩn chứa nhiều rủi ro mà chỉ có thể phát hiện ở giai đoạn cuối cùng (được minh họa trong hình 1) và chi phí để sửa chữa có thể rất cao.

v Ứng dụng:

Yêu cầu được định nghĩa rất rõ ràng, chi tiết và hầu như không thay đổi, thường xuất phát từ sản phẩm đã đạt mức ổn định.

Yêu cầu mới bổ sung (nếu có) cũng sớm được xác định rõ ràng, đầy đủ từ đầu dự án.

Đội ngũ thực hiện quen thuộc và hiểu rõ tất cả yêu cầu của dự án, và có nhiều kinh nghiệm với các công nghệ được dùng để phát triển sản phẩm.

Dự án được xác định hầu như không có rủi ro.

2.Mô hình phát triển nhanh:

-Tập trung vào xây dựng nhanh phần mềm dựa trên các thành phần cơ bản có thể sử dụng chung, có thể sử dụng lại

ü Mô hình hoá nghiệp vụ: Luồng thông tin giữa các chức năng nghiệp vụ được mô hình hoá

ü Mô hình hoá dữ liệu: xác định các đối tượng dữ liệu, các thuộc tính và các mối quan hệ

ü Mô hình hoá tiến trình: tạo ra các tiến trình để thêm, sửa, xoá, lấy thông tin của các đối tượng dữ liệu

ü Xây dựng ứng dụng: Thông thường sử dụng hỗ trợ của các công cụ tự động và dùng lại các thành phần sẵn có

ü Kiểm thử: kiểm thử các thành phần mới thêm vào, sự tích hợp giữa chúng

v Ưu điểm:

-Cho phép giảm thời gian phát triển các ứng dụng CSDL và có nhiều giao diện người dùng hay tích hợp các thành phần có sẵn.

-Cần một nguồn nhân lực lớn trong nhóm làm việc

-Người sử dụng sẽ tham gia vào các hoạt động kiểm thử.

v Nhược điểm:

-Khó có sự nhất quán giữa những thành phần được phát triển bởi các nhóm khác nhau.

-Không phù hợp cho những ứng dụng đòi hỏi hiệu suất vì thường phụ thuộc vào sự hỗ trợ của môi trường phát triển và ngôn ngữ cấp cao.

v Ứng dụng: chỉ phù hợp với các loại ứng dụng có thể tách thành các Modul rời rạc rõ ràng, có thể có nhiều thành phần dùng chung, nhiều thành phần dùng lại.

3.Mô hình tăng trưởng:

-Là sự kết hợp giữa mô hình tuần tự và mô hình bản mẫu

-Mỗi dãy tuần tự tạo ra một kết quả có tính tăng trưởng của phần mềm

-Kết quả đạt được đầu tiên là sản phẩm lõi đáp ứng những yêu cầu cơ bản mà chưa có tính năng nâng cao. Sau đó, nó được đưa cho khách hàng sử dụng và đánh giá

-Xây dựng kế hoạch: sửa đổi sản phẩm lõi để đáp ứng yêu cầu khách hàng và bổ sung những tính năng mới

-Quá trình này lặp lại và đưa ra những kết quả tăng trưởng cho đến khi có được một sản phẩm hoàn thiện

v Ưu điểm:

-Rủi ro được phân tích và xác định ngay từ đầu.

-Giao tiếp giữa các module cũng được xác định rõ ràng từ đầu.

-Đội ngũ phát triển quen thuộc với lĩnh vực của dự án và có nhiều kinh nghiệm.

-Giảm rủi ro sớm trong chu kỳ phát triển phần mềm.

- Những yêu cầu quan trọng thường được phát triển và chuyển đến người sử dụng sớm.

-Phản hồi của nguời sử dụng về những vấn đề phát sinh trong phiên bản trước được dùng để cải tiến và ngăn ngừa những vấn đề tương tự xảy ra trong những phiên bản tiếp theo.

v Nhược điểm:

-Tổng chi phí lập kế hoạch phát triển cho toàn hệ thống có thể cao hơn. Lưu ý, ở đây chỉ đề cập chi phí lập kế hoạch ban đầu, không bao gồm tất cả chi phí phát sinh. Trong thực tế, nếu ứng dụng hợp lý, toàn bộ chi phí và thời gian cho đến khi sản phẩm được nghiệm thu có thể thấp hơn so với mô hình khác.

-Các yêu cầu về kế hoạch và hoạt động trong qui trình cụ thể sẽ phức tạp hơn.

v Ứng dụng: Hệ thống lớn được phát triển trong thời gian dài, khách hàng cần triển khai sớm một số phần của hệ thống.

.Mô hình xoắn ốc:

Ø Đây là mô hình phát triển từ mô hình thác nước cho thấy mức độ tổng quát hơn của các pha sản xuất của một sản phẩm. Được xây dựng theo một dãy các kết quả tăng trưởng.

Ø Mô hình này có thể chỉ ra các rủi ro có thể hình thành trên căn bản của mô hình quá trình (sản xuất) tổng quát.

Ø Mỗi vòng lặp đại diện cho một pha của quá trình phần mềm. Vòng trong cùng tập trung về tính khả thi, vòng kế lo về định nghĩa các yêu cầu, kế đến là thiết kế, ...

Ø Không có một pha nào được xem là cố định trong vòng xoắn. Mỗi vòng có 6 phần tương ứng với một pha:

ü Giao tiếp với khách hàng: thiết lập sự giao tiếp có hiệu quả giữa người phân tích và khách hàng.

ü Lập kế hoạch: Xác định tài nguyên, thời gian và các thông tin liên quan khác.

ü Phân tích rủi ro: Đánh giá và quản lý các rủi ro có thể có ở từng giai đoạn.

ü Xây dựng ứng dụng: Áp dụng công nghệ để xây dựng ứng dụng.

ü Chuyển giao: kiểm thử cài đặt và hỗ trợ khách hàng.

ü Đánh giá của khách hàng: Ghi nhận phản hồi của người sử dụng để chuẩn bị cho các công việc ở giai đoạn tiếp theo.

v Ưu điểm:

-Phân tích đánh giá rủi ro được đẩy lên như một phần thiết yếu trong mỗi “spiral” để tăng mức độ tin cậy của dự án.

-Kết hợp những tính chất tốt nhất của mô hình waterfall và tiến hóa.

-Cho phép thay đổi tùy theo điều kiện thực tế dự án tại mỗi “spiral”.

-Có sự kết hợp của các mô hình khác vào phát triển nên khắc phục được nhiều nhược điểm của các mô hình khác.

-Một rủi ro nào đó không được giải quyết thì chấm dứt.

-Kiểm soát rủi ro ơ từng giai đoạn phát triển.

-Đánh gia chi phí chính xác hơn các phương pháp khác.

-Đây chính là mô hình tổng quát nhất, tất cả các mô hình khác đều có thể xem là một hiện thực của mô hình tổng quát này, hay cũng có thể xem nó là mô hình tổng hợp các mô hình khác. Đặc biệt, nó được ứng dụng không chỉ trong phát triển phần mềm mà còn trong phát triển phần cứng.

v Nhược điểm:

-Phức tạp và không phù hợp cho dự án nhỏ với ít rủi ro.

-Cần có kỹ năng tốt về phân tích rủi ro.

-Yêu cầu thay đổi thường xuyên dẫn đến lặp vô hạn.

-Chưa được dùng rộng dãi như mô hình thác nước hay là mẫu.

-Đòi hỏi năng lực quản lý

v Ứng dụng: Trong những dự án lớn có nhiều rủi ro hay sự thành công của dự án không có được sự đảm bảo nhất định;

- Những dự án đòi hỏi nhiều tính toán, xử lý như hệ thống hỗ trợ quyết định.

Câu 2: “Nếu lịch trình bị trễ, ta có thể bổ sung các lập trình viên vào dự án đề hoàn thành dự án nhanh hơn”. Trình bày quan điểm của bạn về điều này?

Điều nói trên là không đúng, bởi vì trên lý thuyết thì có thể làm thế được, nhưng thực tế, quá trình sản xuất một dự án phần mềm diễn ra hết sức phức tạp bao gồm nhiều khâu, nhiều giai đoạn khác nhau đòi hỏi mỗi thành viên trong dự án phần mềm đó phải nắm rõ tất cả các vấn đề, có sự thống nhất ý kiến, đồng quan điểm. Quá trình này diễn ra tương đối dài, có thể từ vài tuần, vài tháng, thậm chí tới vài năm mới có thể hình thành bảng phác thảo chi tiết dự án. Vì thế, người lập trình viên muốn xây dựng được dự án thì trước hết phải tham gia trực tiếp vào qua trình xây dựng dự án từ đầu. Trên cơ sở đó, họ mới có thể bắt tay vao xây dựng được dự án đã đặt ra. Vì thế không thể nào một người không hiểu sâu về dự án, thậm chí không biết gì về dự án thì không thể nào hoàn thành tốt dự án được. Mà giả sử có làm được thì chất lượng sản phẩm phần mềm đó cũng không đáp ứng được yêu cầu đặt ra, và có thể phát sinh lỗi!