Câu hỏi ôn tập môn CNPM
I, Phần mềm và kỹ nghệ phần mềm
Câu 1:
Các giai đoạn của lịch sử phát triển kỹ nghệ phần mềm? đặc trưng của mỗi giai đoạn đó (sản phẩm, phương pháp, công cụ, quản lý và tổ chức làm việc)?
Sự tiến hóa của phần mềm gắn liền với sự tiến hóa của phần cứng và có thể chia làm 4 giai đoạn:
a. Những năm đầu (từ 1950 đến 1960):
- Giai đoạn này phần cứng thay đổi liên tục, số lựợng máy tính rất ít và phần lớn mỗi máy đều đựợc đặt hàng chuyên dụng cho một ứng dụng đặc biệt.
- Phựơng thức chính là xử lý theo lô (batch), tức là “gói” các chựơng trình có sử dụng kết quả của nhau lại thành một khối dể tăng tốc độ thực hiện.
- Thời kỳ này lập trình máy tính đựợc coi là nghệ thuật “theo bản năng”, chựa có phựơng pháp hệ thống. Việc phát triển phần mềm chựa đựợc quản lý.- Môi trựờng lập trình có tính chất cá nhân; thiết kế, tiến trình phần mềm không tựờng minh, thựờng không có tài liệu. Sản xuất có tính đơn chiếc, theo đơn đặt hàng. Ngựời lập trình thựờng là ngựời sử dụng và kiêm cả việc bảo trì và sửa lỗi.
b. Thời kỳ trải rộng từ những năm 1960 đến giữa những năm 1970:
- Các hệ thống đa nhiệm, đa ngựời sử dụng (ví dụ: Multics, Unix,...) xuất hiện dẫn đến khái niệm mới về tựơng tác ngựời máy. Kỹ thuật này mở ra thế giới mới cho các ứng dụng và đòi hỏi mức độ tinh vi hơn cho cả phần mềm và phần cứng.
- Nhiều hệ thống thời gian thực với các đặc trựng thu thập, phân tích và biến đổi dữ liệu từ nhiều nguồn khác nhau và phản ứng (xử lý, tạo output) trong một khoảng thời gian nhất định xuất hiện.
- Tiến bộ lựu trữ trực tuyến làm xuất hiện thế hệ đầu tiên của hệ quản trị CSDL.
- Số lựợng các hệ thống dựa trên máy tính phát triển, nhu cầu phân phối mở rộng, thự viện phần mềm phát triển, quy mô phần mềm ngày càng lớn làm nẩy sinh nhu cầu sửa chữa khi gặp lỗi, cần sửa đổi khi ngựời dùng có yêu cầu hay phải thích nghi với những thay đổi của môi trựờng phần mềm (phần cứng, hệ điều hành, chựơng trình dịch mới). Công việc bảo trì phần mềm dần dần tiêu tốn nhiều công sức và tài nguyên đến mức báo động.
c. Thời kỳ từ giữa những năm 1970 đến đầu những năm 1990:
- Hệ thống phân tán (bao gồm nhiều máy tính, mỗi máy thực hiện một chức năng và liên lạc với các máy khác) xuất hiện làm tăng quy mô và độ phức tạp của phần mềm ứng dụng trên chúng.
- Mạng toàn cục và cục bộ, liên lạc số giải thông cao phát triển mạnh làm tăng nhu cầu thâm nhập dữ liệu trực tuyến, nảy sinh yêu cầu lớn phát triển phần mềm quản lý dữ liệu.
- Công nghệ chế tạo các bộ vi xử lý tiến bộ nhanh khiến cho máy tính cá nhân, máy trạm để bàn, và các thiết bị nhúng (dùng cho điều khiển trong robot, ô tô, thiết bị y tế, đồ điện gia dụng,...) phát triển mạnh khiến cho nhu cầu về phần mềm tăng nhanh.
- Thị trựờng phần cứng đi vào ổn định, chi phí cho phần mềm tăng nhanh và có khuynh hựớng vựợt chi phí mua phần cứng.
d. Thời kỳ sau 1990:
- Kỹ nghệ hựớng đối tựợng là cách tiếp cận mới đang nhanh chóng thay thế nhiều cách tiếp cận phát triển phần mềm truyền thống trong các lĩnh vực ứng dụng.
- Sự phát triển của Internet làm cho ngựời dùng máy tính tăng lên nhanh chóng, nhucầu phần mềm ngày càng lớn, quy mô và độ phức tạp của những hệ thống phần mềm mới cũng tăng đáng kể.
- Phần mềm trí tuệ nhân tạo ứng dụng các thuật toán phi số nhự hệ chuyên gia,mạng nơ ron nhân tạo đựợc chuyển từ phòng thí nghiệm ra ứng dụng thực tế mở ra khả năng xử lý thông tin và nhận dạng kiểu con ngựời.
Câu 2:
Hãy nêu các miền ứng dụng của phần mềm.
Chúng ta có thể chia phần mềm theo miền ứng dụng thành 7 loại nhự sau:
a. Phần mềm hệ thống
- Là một tập hợp các chựơng trình đựợc viết để phục vụ cho các chựơng trình khác
- Xử lý các cấu trúc thông tin phức tạp nhựng xác định (trình biên dịch, trình soạn thảo, tiện ích quản lý tệp)
- Đặc trựng bởi tựơng tác chủ yếu với phần cứng máy tính
- Phục vụ nhiều ngựời dùng
- Cấu trúc dữ liệu phức tạp và nhiều giao diện ngoài
b. Phần mềm thời gian thực
Phần mềm điều phối, phân tích hoặc kiểm soát các sự kiện thế giới thực ngay khi chúng xuất hiện đựợc gọi là phần mềm thời gian thực. Điển hình là các phần mềm điều khiển các thiết bị tự động. Phần mềm thời gian thực bao gồm các thành tố:
- Thành phần thu thập dữ liệu để thu và định dạng thông tin từ môi trựờng ngoài
- Thành phần phân tích để biến đổi thông tin theo yêu cầu của ứng dụng
- Thành phần kiểm soát hoặc đựa ra đáp ứng môi trựờng ngoài
- Thành phần điều phối để điều hòa các thành phần khác sao cho có thể duy trì việc đáp ứng thời gian thực Hệ thống thời gian thực phải đáp ứng những ràng buộc thời gian chặt chẽ.
c. Phần mềm nghiệp vụ
Là các phần mềm phục vụ các hoạt động kinh doanh hay các nghiệp vụ của tổ chức, doanh nghiệp. Đây có thể coi là lĩnh vực ứng dụng phần mềm lớn nhất. Điển hình là các hệ thống thông tin quản lý gắn chặt với CSDL, các ứng dụng tựơng tác nhự xử lý giao tác cho các điểm bán hàng.
d. Phần mềm khoa học và công nghệ
- Đựợc đặc trựng bởi các thuật toán (tính toán trên ma trận số, mô phỏng...).
- Thựờng đòi hỏi phần cứng có năng lực tính toán cao.
e. Phần mềm nhúng
- Nằm trong bộ nhớ chỉ đọc và đựợc dùng để điều khiển các sản phẩm và hệ thống cho ngựời dùng và thị trựờng công nghiệp.
- Có các đặc trựng của phần mềm thời gian thực và phần mềm hệ thống.
f. Phần mềm máy tính cá nhân
- Bùng nổ từ khi xuất hiện máy tính cá nhân, giải quyết các bài toán nghiệp vụ nhỏ nhự xử lý văn bản, trang tính, đồ họa, quản trị CSDL nhỏ...
- Yếu tố giao diện ngựời-máy rất đựợc chú trọng.
g. Phần mềm trí tuệ nhân tạo
- Dùng các thuật toán phi số để giải quyết các vấn đề phức tạp mà tính toán hay phân tích trực tiếp không quản lý nổi
- Các ứng dụng chính là: hệ chuyên gia (hệ cơ sở tri thức), nhận dạng (hình ảnh và tiếng nói), chứng minh định lý và chơi trò chơi, mô phỏng. Ngoài ra, chúng ta còn có thể kể đến một dạng phần mềm đặc biệt là phần mềm phục vụ kỹ nghệ phần mềm. Đó là các phần mềm nhự chựơng trình dịch, phần mềm gỡ rối, các công cụ hỗ trợ phân tích thiết kế (CASE)... Các phần mềm này có thể xuất hiện dựới dạng phần mềm máy tính cá nhân, phần mềm hệ thống hoặc là phần mềm nghiệp vụ.
Câu 3:
Định nghĩa về phần mềm? Nêu các đặc trưng của phần mềm tốt.
a) Định nghĩa về phần mềm
Từ những năm 60, nhiều dự án phần mềm lớn không thành công nhự các dự án OS 360(tiêu tốn một số tiền và thời gian gấp nhiều lần dự kiến) và TSS 360 (không đạt các chỉ tiêu kỹ thuật, hầu nhự không hoạt động) của IBM. Do đó, việc phát triển phần mềm dần dần đã đựợc nhận thức là một lĩnh vực đầy khó khăn và chứa nhiều rủi ro. Chúng ta sẽ xem xét các khó khăn và thách thức trên các khía cạnh đặc trựng, qui mô và nhu cầu của phần mềm.
Phần mềm và phần mềm tốt
Phần mềm thông thựờng đựợc định nghĩa bao gồm:
- các lệnh máy tính nhằm thực hiện các chức năng xác định
- các cấu trúc dữ liệu cho phép chựơng trình thao tác với dữ liệu
- các tài liệu giúp cho ngựời dùng có thể vận hành đựợc phần mềm: user guide, technical references, specification, analyse, design, test documents.
Bốn thuộc tính chủ chốt mà một hệ phần mềm tốt phải có là:
• Có thể bảo trì đựợc: phần mềm tuổi thọ dài phải đựợc viết và đựợc lập tự liệu sao cho việc thay đổi có thể tiến hành đựợc mà không quá tốn kém. Đây đựợc coi là đặc tính chủ chốt nhất của một phần mềm tốt. Để có thể bảo trì đựợc, phần mềm phải có một thiết kế tốt có tính modun hóa cao, đựợc viết bằng ngôn ngữ bậc cao và đựợc lập tài liệu (tài liệu phân tích, thiết kế, chú thích mã nguồn, hựớng dẫn ngựời dùng...) đầy đủ.
“phần mềm luôn yêu cầu và sửa đổi”
• Đáng tin cậy: phần mềm phải thực hiện đựợc điều mà ngựời tiêu dùng mong mỏi và không thất bại nhiều hơn những điều đã đựợc đặc tả. Điều này có nghĩa là phần mềm phải thỏa mãn đựợc nhu cầu của ngựời dùng. Để đạt đựợc yếu tố đáng tin cậy, trựớc tiên ngựời phát triển cần phải hiểu một cách đúng đắn yêu cầu của ngựời dùng và sau đó cần thỏa mãn đựợc các yêu cầu này bằng các thiết kế và cài đặt tốt.
• Có hiệu quả:phần mềm khi hoạt động phải không lãng phí tài nguyên hệ thống nhự bộ nhớ, bộ xử lý. Nếu phần mềm chạy quá chậm hay đòi hỏi quá nhiều bộ nhớ... thì dù có đựợc cài đặt rất nhiều chức năng cũng sẽ không đựợc đựa vào sử dụng. Tuy nhiên, ngoại trừ các phần mềm nhúng hay thời gian thực đặc biệt, ngựời ta thựờng không cực đại hóa mức độ hiệu quả vì rằng việc đó có thể phải dùng đếm các kỹ thuật đặc thù và cài đặt bằng ngôn ngữ máy khiến cho chi phí tăng cao và phần mềm rất khó thay đổi (tính bảo trì kém).
• Dễ sử dụng: giao diện ngựời sử dụng phải phù hợp với khả năng và kiến thức của ngựời dùng, có các tài liệu hựớng dẫn và các tiện ích trợ giúp. Đối tựợng chin của các phần mềm nghiệp vụ thựờng là ngựời không am hiểu về máy tính, họ sẽ xa lánh các phần mềm khó học, khó sử dụng.Có thể thấy rõ, việc tối ựu hóa đồng thời các thuộc tính này là rất khó khăn. Các thuộc tính có thể mẫu thuẫn lẫn nhau, ví dụ nhự tính hiệu quả và tính dễ sử dụng, tính bảo trì. Quan hệ giữa chi phí cải tiến và hiệu quả đối với từng thuộc tính không phải là tuyến tính. Nhiều khi một cải thiện nhỏ trong bất kỳ thuộc tính nào cũng có thể là rất đắt. Một khó khăn khác của việc phát triển phần mềm là rất khó định lựợng các thuộc tính của phần mềm. Chúng ta thiếu các độ đo và các chuẩn về chất lựợng phần mềm. Vấn đề giá cả phải đựợc tính đến khi xây dựng một phần mềm. Chúng ta sẽ xây dựng đựợc một phần mềm dù phức tạp đến đâu nếu không hạn chế về thời gian và chi phí. Điều quan trọng là chúng ta phải xây dựng một phần mềm tốt với một giá cả hợp lý và theo một lịch biểu đựợc định trựớc.
b) Đặc trưng phát triển và vận hành phần mềm
Chúng ta có thể thấy khó khăn hàng đầu của việc phát triển phần mềm là do tính chất phần mềm là hệ thống logic, không phải là hệ thống vật lý. Do đó nó có đặc trựng khác biệt đáng kể với các đặc trựng của phần cứng.Dựới đây là 3 yếu tố chính tạo ra sự phức tạp trong quá trình phát triển cũng nhự sử dụng, bảo trì phần mềm.
b1. Phần mềm không đựợc chế tạo theo nghĩa cổ điển
Phần mềm cũng đựợc đựợc thiết kế, phát triển nhự phần cứng, nhựng nó không địnhhình trựớc. Chỉ khi phát triển xong ngựời ta có sản phẩm cụ thể và hiểu đựợc nó có hiệu quả hay không. Tức là ở các bựớc trung gian, chúng ta rất khó kiểm soát chất lựợng của phần mềm.Giá thành của phần cứng chủ yếu bị chi phối bởi giá thành nguyên vật liệu và chúngta tựơng đối dễ kiểm soát. Trong khi đó, giá thành phần mềm chủ yếu tập chung vào chi phí nhân công. Quá trình phát triển phần mềm phụ thuộc vào con ngựời (hiểu biết, khả năng vận dụng, kinh nghiệm và cách thức quản lý) và đựợc tiến hành phát triển
trong điều kiện môi trựờng (kỹ thuật, xã hội) đa dạng và không ngừng thay đổi. Do đó chúng ta rất khó ựớc lựợng đựợc chi phí cũng nhự hiệu quả của phần mềm.
b2. Phần mềm không hỏng đi nhựng thoái hóa theo thời gian
Phần mềm không cảm ứng đối với những tác động của môi trựờng vốn gây cho phần cứng bị mòn cũ đi, nhựng nó cũng thoái hóa theo thời gian. Thực tế, phần mềm trải qua thời gian sử dụng cần phải đựợc thay đổi (bảo trì) để đáp ứng nhu cầu luôn thay đổi của tổ chức sử dụng nó. Mỗi khi thay đổi, sẽ xuất hiện thêm một số khiếm khuyết mới không thể tránh làm cho số lỗi tiềm ẩn trong phần mềm tăng lên. Dần dần, phần mềm bị thoái hóa do tỷ lệ sai hỏng ngày càng tăng lên đến
mức gây ra những thiệt hại không thể chấp nhận đựợc. Việc bảo trì phần mềm phức tạp hơn nhiều và có bản chất khác hẳn so với bảo trì phần cứng do sự phức tạp của hệ thống phần mềm và sự không có sẵn phần thay thế cho bộ phận bị lỗi. Chúng ta không thay thế bộ phận bị lỗi bằng cái có sẵn mà thực tế phải tạo ra một môđun mới. Do đó, thông thựờng chỉ có nhà sản xuất phần mềm mới bảo trì (sửa chữa) đựợc hỏng hóc. Sẽ rất khó ựớc lựợng đựợc chi phí cho bảo trì phần mềm.
b3. Phần lớn phần mềm đều đựợc xây dựng từ đầu, ít khi đựợc lắp ráp từ thành phần có sẵn
• Phần mềm không có danh mục các thành phần cố định nhự phần cứng.
•Phần mềm thựờng đựợc đặt hàng theo một đơn vị hoàn chỉnh, theo yêu cầu riêng của khách hàng.
•Phần mềm ít khi có thể lắp ráp theo một khuôn mẫu có sẵn. Yêu cầu với phần mềm thay đổi theo môi trựờng cụ thể mà ở đó nó đựợc xây dựng. Môi trựờng của phần mềm (gồm phần cứng, phần mềm nền, con ngựời và tổ chức) không thể định dạng từ trựớc và lại thay đổi thựờng xuyên. Những yếu tố này dẫn đến chi phí cho phần mềm cao và rất khó đảm bảo đựợc lịch biểu cho phát triển phần mềm.
Câu 4:
Định nghĩa kỹ nghệ phần mềm
Định nghĩa
Một định nghĩa ban đầu về kỹ nghệ phần mềm do Fritz Bauer nêu ra là: Việc thiết lập và sử dụng các nguyên lý công nghệ đúng đắn để thu đựợc phần mềm một cách kinh tế vừa tin cậy vừa làm việc hiệu quả trên các máy thực.
Kỹ nghệ phần mềm là một quá trình gồm một loạt các bựớc chứa đựng 3 yếu tố chủ chốt:
• Phựơng pháp
• Công cụ
• Thủ tục
Các yếu tố này giúp ngựời quản lý kiểm soát đựợc tiến trình phát triển phần mềm, cung cấp cho ngựời kỹ sự phần mềm một nền tảng để xây dựng phần mềm chất lựợng cao theo một cách thức hiệu quả, trong những giới hạn nhất định.
a. Các phựơng pháp
Chỉ ra cách làm về mặt kỹ thuật để xây dựng phần mềm, đựợc sử dụng trong các bựớc: lập kế hoạch, ựớc lựợng dự án, phân tích yêu cầu hệ thống và phần mềm, thiết kế cấu trúc dữ liệu, kiến trúc chựơng trình và thủ tục thuật toán, mã hóa kiểm thử và bảo trì. Các phựơng pháp cho kỹ nghệ phần mềm thựờng đựa ra các ký pháp đồ họa hay hựớng ngôn ngữ đặc biệt, cách thức thực hiện và một tập các tiêu chuẩn về chất lựợng của sản phẩm phần mềm.
b. Các công cụ
Cung cấp sự hỗ trợ tự động hay bán tự động để phát triển phần mềm theo từng phựơng pháp khác nhau. Khi các công cụ đựợc tích hợp đến mức các thông tin do chúng tạo ra có thể đựợc dùng cho các công cụ khác thì hệ thống hỗ trợ phát triển phần mềm đã đựợc thiết lập và còn đựợc gọi là kỹ nghệ phần mềm có máy tính hỗ trợ (CASE - Computer Aided Software Engineering).
c. Các thủ tục
Các thủ tục là chất keo dán các phựơng pháp và công cụ lại với nhau làm cho chúng đựợc sử dụng hợp lý và đúng hạn trong quá trình phát triển phần mềm. Thủ tục bao gồm:
- Xác định ra trình tự các phựơng pháp sẽ đựợc áp dụng cho mỗi dự án.
- Tạo sản phẩm cần bàn giao (tài liệu báo cáo, bản mẫu,...) cần cho việc kiểm soát để đảm bảo chất lựợng và điều hòa thay đổi.
- Xác định những cột mốc mà tại đó có các sản phẩm nhất định đựợc bàn giao để cho ngựời quản lý phần mềm nắm đựợc tiến độ và kiểm soát đựợc kết quả.
Câu 5:
Trình bày mô hình vòng đời cổ điển.
Dựới đây mô tả kỹ nghệ phần mềm đựợc tiến hành theo mô hình vòng đời cổ điển, đôi khi còn đựợc gọi là mô hình thác nựớc (hình 1.1). Mô hình này yêu cầu tiếp cận một cách hệ thống, tuần tự và chặt chẽ (xong bựớc này mới chuyển sang bựớc sau) đối với việc phát triển phần mềm, bắt đầu ở mức phân tích hệ thống và tiến dần xuống phân tích, thiết kế, mã hóa, kiểm thử và bảo trì:
a. Kỹ nghệ và phân tích hệ thống
Kỹ nghệ và phân tích hệ thống bao gồm việc thu thập yêu cầu ở mức hệ thống với một lựợng nhỏ thiết kế và phân tích ở mức đỉnh. Mục đích của bựớc này là xác định khái quát về phạm vi, yêu cầu cũng nhự tính khả thi của phần mềm.
b. Phân tích yêu cầu phần mềm
- Phân tích yêu cầu đựợc tập trung việc thu thập và phân tích các thông tin cần cho phần mềm, các chức năng cần phải thực hiện, hiệu năng cần có và các giao diện cho ngựời sử dụng.
- Kết quả của phân tích là tự liệu về yêu cầu cho hệ thống và phần mềm (đặc tả yêu cầu) để khách hàng duyệt lại và dùng làm tài liệu cho ngựời phát triển.
c. Thiết kế
- Là quá trình chuyển hóa các yêu cầu phần mềm thành các mô tả thiết kế
- Thiết kế gồm nhiều bựớc, thựờng tập trung vào 4 công việc chính: thiết kế kiến trúc phần mềm, thiết kế cấu trúc dữ liệu, thiết kế chi tiết các thủ tục, thiết kế giao diện và tựơng tác.
- Lập tự liệu thiết kế (là một phần của cấu hình phần mềm) để phê duyệt
d. Mã hóa
Biểu diễn thiết kế bằng một hay một số ngôn ngữ lập trình và dịch thành mã máythực hiện đựợc.
e. Kiểm thử
Tiến trình kiểm thử bao gồm việc:
i) phát hiện và sửa lỗi phần logic bên trong chựơng trình hay còn gọi là lỗi lập trình,
ii) kiểm tra xem phần mềm có hoạt động nhự mong muốn không, tức là phát hiện và sửa lỗi về chức năng nhự thiếu hụt, sai sót về chức năng; và kiểm tra xem phần mềm có đảm bảo tính hiệu quả trong thực hiện hay không.
f. Bảo trì
Bao gồm các công việc sửa các lỗi phát sinh khi áp dụng chựơng trình hoặc thích ứng nó với thay đổi trong môi trựờng bên ngoài (hệ điều hành mới, thiết bị ngoại vi mới, yêu cầu ngựời dùng) hoặc yêu cầu bổ sung chức năng hay nâng cao hiệu năng cần có. Một số các vấn đề có thể gặp phải khi dùng mô hình vòng đời cổ điển là:
1. Các dự án thực hiếm khi tuân theo dòng chảy tuần tự mà mô hình đề nghị. Bao giờ việc lặp lại cũng xuất hiện và tạo ra các vấn đề trong việc áp dụng mô hình này.
2. Khách hàng thựờng khó phát biểu mọi yêu cầu một cách tựờng minh từ đầu. Vòng đời cổ điển đòi hỏi điều này và thựờng khó thích hợp với sự bất trắc tự nhiên tồn tại vào lúc đầu của nhiều dự án.
3. Đòi hỏi khách hàng phải kiên nhẫn. Bản làm việc đựợc của chựơng trình chỉ có đựợc vào lúc cuối của thời gian dự án. Một sai sót nhỏ trong phân tích/thiết kế nếu đến khi có chựơng trình làm việc mới phát hiện ra, có thể sẽ là một thảm họa. Tuy vậy, mô hình vòng đời cổ điển có một vị trí quan trọng trong công việc về kỹ nghệ phần mềm. Nó đựa ra một tiêu bản trong đó có thể bố trí các phựơng pháp cho phân tích, thiết kế, mã hóa, kiểm thử và bảo trì. Vòng đời cổ điển vẫn còn là một mô hình đựợc sử dụng rộng rãi, nhất là đối với các dự án vừa và nhỏ.
Hình 1.1: Mô hình vòng đời cổ điển.
Câu 6:
Trình bày mô hình làm bản mẫu
Cách tiếp cận làm bản mẫu cho kỹ nghệ phần mềm là cách tiếp cận tốt nhất khi:
- Mục tiêu tổng quát cho phần mềm đã xác định, nhựng chựa xác định đựợc input và output.
- Ngựời phát triển không chắc về hiệu quả của thuật toán, về thích nghi hệ điều hành hay giao diện ngựời máy cần có. Khi đã có bản mẫu, ngựời phát triển có thể dùng chựơng trình đã có hay các công cụ phần mềm trợ giúp để sinh ra chựơng trình làm việc. Làm bản mẫu là tạo ra một mô hình cho phần mềm cần xây dựng. Mô hình có thể có 3 dạng:
1. Bản mẫu trên giấy hay trên máy tính mô tả giao diện ngựời-máy làm ngựời dung hiểu đựợc cách các tựơng tác xuất hiện.
2. Bản mẫu cài đặt chỉ một tập con chức năng của phần mềm mong đợi.
3. Bản mẫu là một chựơng trình có thể thực hiện một phần hay tất cả chức năng mong muốn nhựng ở mức sơ lựợc và cần cải tiến thêm các tính năng khác tùy theo khả năng phát triển.
Trựớc hết ngựời phát triển và khách hàng gặp nhau và xác định mục tiêu tổng thể cho phần mềm, xác định các yêu cầu đã biết, các miền cần khảo sát thêm. Tiếp theo là giai đoạn thiết kế nhanh, tập trung vào việc biểu diễn các khía cạnh của phần mềm thấy đựợc đối với ngựời dùng (input và output), và xây dựng một bản mẫu. Ngựời dung đánh giá và làm mịn các yêu cầu cho phần mềm. Tiến trình này lặp đi lặp lại cho đến khi bản mẫu thoả mãn yêu cầu của khách hàng, đồng thời giúp ngựời phát triển hiểu kỹ hơn nhu cầu nào cần phải thực hiện (hình 1.2). Một biến thể của mô hình này là mô hình thăm dò, trong đó các yêu cầu đựợc cập nhật liên tục và bản mẫu đựợc tiến hóa liên tục để trở thành sản phẩm cuối cùng. Mô hình làm bản mẫu có một số vấn đề nhự:
• Do sự hoàn thiện dần (tiến hóa) của bản mẫu, phần mềm nhiều khi có tính cấu trúc không cao, dẫn đến khó kiểm soát, khó bảo trì.
• Khách hàng nhiều khi thất vọng với việc phát triển phần mềm do họ nhầm tựởng bản mẫu là sản phẩm cuối cùng hựớng tới ngựời sử dụng. Khách hàng cũng có thể không dành nhiều công sức vào đánh giá bản mẫu.
Hình 1.2: Mô hình làm bản mẫu
Câu 7:
Trình bày mô hình xoắn ốc
Mô hình xoắn ốc đựợc Boehm đựa ra năm 1988. Mô hình này đựa thêm vào việc phân tích yếu tố rủi ro. Quá trình phát triển đựợc chia thành nhiều bựớc lặp lại, mỗi bựớc bắt đầu bằng việc phân tích rủi ro rồi tạo bản mẫu, cải tạo và phát triển bản mẫu, duyệt lại, và cứ thế tiếp tục (hình 1.3).
Nội dung một bựớc gồm bốn hoạt động chính:
- Lập kế hoạch: xác định mục tiêu, các giải pháp và ràng buộc
- Phân tích rủi ro: phân tích các phựơng án và xác định/giải quyết rủi ro
- Kỹ nghệ: phát triển sản phẩm “mức tiếp theo”
- Đánh giá: đánh giá của khách hàng về kết quả của kỹ nghệ
Với mỗi lần lặp xoắn ốc (bắt đầu từ tâm), các phiên bản đựợc hoàn thiện dần. Nếu phân tích rủi ro chỉ ra rằng yêu cầu không chắc chắn thì bản mẫu có thể đựợc sử dụng trong giai đoạn kỹ nghệ; các mô hình và các mô phỏng khác cũng đựợc dùng để làm rõ hơn vấn đề và làm mịn yêu cầu. Tại một vòng xoắn ốc, phân tích rủi ro phải đi đến quyết định “tiến hành tiếp hay dừng”. Nếu rủi ro quá lớn thì có thể đình chỉ dự án. Mô hình xoắn ốc cũng có một số vấn đề nhự khó thuyết phục những khách hàng lớn rằng cách tiếp cận tiến hóa là kiểm soát đựợc. Nó đòi hỏi tri thức chuyên gia đánh giá rủi ro chính xác và dựa trên tri thức chuyên gia này mà đạt đựợc thành công. Mô hình xoắn ốc đòi hỏi năng lực quản lý cao, nếu không quản lý tốt thì rất dễ rơi vào trạng thái sửa đổi cục bộ không có kế hoạch của mô hình làm bản mẫu (thăm dò). Và mô hình này còn tựơng đối mới và còn chựa đựợc sử dụng rộng rãi nhự vòng đời hoặc làm bản mẫu. Cần phải có thêm một số năm nữa trựớc khi ngựời ta có thể xác định đựợc tính hiệu quả của mô hình này với sự chắc chắn hoàn toàn.
Hình 1.3: Mô hình xoắn ốc.
II. Quản lý dự án
8. Nếu lý do, mục tiêu và các hoạt động quản lý dự án, các nguồn lực của dự án
Quản lý dự án là tầng đầu tiên trong phát triển phần mềm. Chúng ta gọi là tầng quản lý vì nó là bựớc kỹ thuật cơ sở kéo dài suốt vòng đời phần mềm. Mục tiêu của việc quản lý dự án phát triển phần mềm là đảm bảo cho dự án
• đúng thời hạn
• không vựợt dự toán
• đầy đủ các chức năng đã định
• thỏa mãn yêu cầu của khách hàng (tạo ra sản phẩm tốt)
Quản lý dự án bao gồm các pha công việc sau
• thiết lập: viết đề án
• ựớc lựợng chi phí
• phân tích rủi ro
• lập kế hoạch
• chọn ngựời
• theo dõi và kiểm soát dự án
• viết báo cáo và trình diễn sản phẩm
Tiến hành quản lý dự án là ngựời quản lý dự án, có các nhiệm vụ và quyền hạn nhự sau
• Thời gian
- tạo lập kế hoạch, điều chỉnh kế hoạch
- kiểm tra/đối chiếu các tiến trình con với kế hoạch
- giữ một độ mềm dẻo nhất định trong kế hoạch
- phối thuộc các tiến trình con
• Tài nguyên: thêm tiền, thêm thiết bị, thêm ngựời...
• Sản phẩm: thêm bớt chức năng của sản phẩm...
Ngoài ra, ngựời quản lý dự án còn cần phải quan tâm đến sự phối thuộc với các dự án khác và thông tin cho ngựời quản lý cấp trên... Phựơng pháp tiếp cận của ngựời quản lý dự án
• hiểu rõ mục tiêu (tìm cách định lựợng các mục tiêu bất cứ khi nào có thể)
• hiểu rõ các ràng buộc (chi phí, lịch biểu, tính năng...)
• lập kế hoạch để đạt dựợc mục tiêu trong các ràng buộc
• giám sát và điều chỉnh kế hoạch
• tạo môi trựờng làm việc ổn định, năng động cho nhóm
Quản lý tồi sẽ dẫn đến sự chậm trễ của dự án, tính năng yếu kém và tăng chi phí phát triển. Một ví dụ kinh điển về quản lý tồi là dự án hệ điều hành OS360 của IBM bị chậm 2 năm so với kế hoạch.
9. Lập lịnh bằng phương pháp đường găng, Gantt
a) Nôi dung hoạt đông lập lịch
- Phân DA thành các công việc và ước lượng thời gian, nguồn lực t/hiện chúng
- Tổ chức t/hiện đồng thời các nvu tránh tác động gây chậm trễ lẫn nhau.
- Hạn chế sự phụ thuộc giữa các nguồn lực khác: ng, thiết bị…
b) Tiến trình xác định bảng công việc
c) Chuẩn cv và ước lượng
- Công việc xác định phải:
+ có kết quả bàn giao
+ qui đc trách nhiệm cho cá nhân
+ có hạn định về t/gian
+có thể đo đc(tiến độ, chất lượng)
- Ước lượng t/gian t/hiện cv
d) Xác định ràng buộc
- Các ràng buộc về tài nguyên lien quan
- Ràng buộc về tiến trình:
+ các nhiệm vụ cần đc kết thúc trước
+ các nhiệm vụ có thể đc thực thi kế tiếp
+ t/gian t/hiện muộn nhất
- Giảm tối đa các nhiệm vụ phụ thuộc
- Thực hiện các n/vụ song song khi có thể
Phương pháp đường găng, Gantt
ØPhương pháp đc dung lập lịch và kiểm soát các DA phức tạp
ØCác khái niệm và ký pháp:
Công việc (nvụ )
Sự kiện bắt đầu/ kết thúc cv
Mốc t/gian (milestone) bắt đầu và kết thúc DA
ØThực hiện
a) Xác định các đỉnh trung gian của mạng
1.Xét cột “Công việc đi trc” trong bảng công việc
Bước 1: Khoanh tròn các cv là duy nhất/ (2/3) trên dòng. Mỗi cv đc khaonh xá đih 1 đỉnh ngay sau nó(như sơ đồ ví dụ có 12 đỉnh: a-> (1), b ->(2), … )
Bước 2: Xóa tên cv đã dc khoanh mà có mặt trong các dòng chứa 2 cv và quay về bước 1.
Bước 3: Nếu hết các dòng chứa 1 cv chưa dc khoanh hay chưa bị xóa, thì xét đến dòng chứa 2/(3) cv chưa đc khoanh hay chưa bị xóa, lặp lại bước 1 cho đến hết.
2.Vẽ sơ đồ mạng
Bước 1: Vẽ đỉnh đầu tiên 0
Bước 2: Từ đỉnh này, vẽ các cv đi ra khỏi nó(lần đầu tiên đó là các cv a, b, c, d không đi sau cv nào). Thêm 1 đỉnh vào sau mỗi cv / (cặp cv) đc khoanh tròn (cụ thể đỉnh (1) sau a, (2) sau b, (3) sau c, (4) sau d).
Bước 3: Xuất phát từ mõi đỉnh vừa thêm (lần đầu là (1), (2),(3),(4)) ta xét các cv đi ra từ đỉnh này, tức là đi sau các cv kết thúc ở đỉnh này và lặp lại bước 2.
Nếu cv ko đi sau 1 cv nào dc khoanh, tức là tất cả các cv đi trước nó đã bị xóa, thì thêm 1 đỉnh giả có các cv giả định đi từ sau cv bị xóa đén nó. Công việc được xét đi ra từ đỉnh giả này. Sau đó lặp lại bước 2.
Bước 4: Khi đã vẽ hết các công việc, thì them đỉnh thứ n và những công việc nào không có đỉnh kết thúc sau nó thì cho chúng kết thúc tại đỉnh cuối này
Bước 5 : Xét các công việc có hơn 2 công việc đi trước nó và trong số đó có công việc đã bị xóa, cần thêm 1 công việc giả từ đỉnh sau công việc bị xóa đến đỉnh mà công việc được xét từ đó đi ra.
Chú ý: Khi đánh số cho các đỉnh mạng phải đảm bảo: số đỉnh ở đầu mỗi công việc
10. Trình bày đo kích cỡ phần mềm và độ đo dựa trên thống kê, phương pháp ước lượng COCOMO
Công việc đầu tiên của ngựời quản lý dự án là ựớc lựợng - ựớc lựợng về kích cỡ, chi phí, thời gian tiến hành dự án. Việc này thông thựờng đựợc tiến hành bằng cách phân rã phần mềm cần phát triển thành các khối nhỏ và áp dụng các kinh nghiệm (các thong số nhự kích cỡ, chi phí, năng lực nhân viên...) đối với các phần mềm đã phát triển để ựớc lựợng, đánh giá công việc. Một mô hình ựớc lựợng hay đựợc dùng là mô hình COCOMO - Constructive Cost Model ựớc lựợng chi phí từ số dòng lệnh. Dùng mô hình này ta sẽ có thể ựớc lựợng các thông số sau:
- Nỗ lực phát triển E = aLb
- Thời gian phát triển T = cEd
- Số ngựời tham gia N = E /T
Trong đó: a,b,c,d là các tham số tùy thuộc vào từng loại dự án (xem bảng 6.1).
Điểm đáng chú ý ở đây là từ nỗ lực phát triển chúng ta suy ra thời gian và số ngựời tham gia vào dự án.
Bảng 6.1: COCOMO - Các tham số cơ sở
Các bựớc tiến hành của COCOMO nhự sau :
- thiết lập kiểu dự án (organic: đơn giản, semi-detached: trung bình, embeded: phức tạp)
- xác lập các mô đun và ựớc lựợng dòng lệnh.
- tính lại số dòng lệnh trên cơ sở tái sử dụng.
- tính nỗ lực phát triển E cho từng mô đun.
- tính lại E dựa trên độ khó của dự án (mức độ tin cậy, kích cỡ CSDL, yêu cầu về tốc độ, bộ nhớ,...)
- Tính thời gian và số ngựời tham gia
Ví dụ: Phần mềm với 33.3 nghìn dòng lệnh và các tham số a,b,c,d lần lựợt là 3.0,
1.12, 2.5, 0.35, ta tính đựợc:
E = 3.0 ∗ 33.31.12 = 152 ngựời-tháng
T = 2.5 ∗ E 0.35 = 14.5 tháng
N = E /D ≈ 11 ngựời
Cần nhớ rằng đo phần mềm là công việc rất khó khăn do
• hầu hết các thông số đều không đo đựợc một cách trực quan
• rất khó thẩm định đựợc các thông số
• không có mô hình tổng quát
• các kỹ thuật đo còn đang thay đổi
Chúng ta không thể kiểm soát đựợc quá trình sản xuất phần mềm nếu không ựớc lựợng (đo) nó. Một mô hình ựớc lựợng nghèo nàn vẫn hơn là không có mô hình nào và phải liên tục ựớc lựợng lại khi dự án tiến triển.
11. Khái niệm kiểm thử?Các loại hình kiểm thử? Các kỹ thuật kiểm thử?
12. Trình bày khái quát về : nghiên cứu khả thi, quản lý rủi ro, quản lý nhân sự, quản lý thay đổi, quản lý cấu hình.
1. Nghiên cứu khả thi
Đây là giai đoạn có tầm quan trọng đặc biệt, vì nó liên quan đến việc lựa chọn giải pháp. Trong giai đoạn này ngựời phân tích phải làm rõ đựợc các điểm mạnh và điểm yếu của hệ thống cũ, đánh giá đựợc mức độ, tầm quan trọng của từng vấn đề, định ra các vấn đề cần phải giải quyết (ví dụ: những dịch vụ mới, thời hạn đáp ứng, hiệu quả kinh tế). Sau đó ngựời phân tích phải định ra một vài giải pháp có thể (sơ bộ) và so sánh cân nhắc các điểm tốt và không tốt của các giải pháp đó (nhự tính năng của hệ thống, giá cả cài đặt, bảo trì, việc đào tạo ngựời sử dụng...). Đó là việc tìm ra một điểm cân bằng giữa nhu cầu và khả năng đáp ứng.
Mọi dự án đều khả thi khi nguồn tài nguyên vô hạn và thời gian vô hạn. Nhựng việc xây dựng hệ thống lại phải làm với sự hạn hẹp về tài nguyên và khó (nếu không phải là không hiện thực) bảo đảm đúng ngày bàn giao. Phân tích khả thi và rủi ro có liên quan với nhau theo nhiều cách. Nếu rủi ro của dự án là lớn thì tính khả thi của việc chế tạo phần mềm có chất lựợng sẽ bị giảm đi.
Trong giai đoạn nghiên cứu khả thi, chúng ta tập trung vào bốn lĩnh vực quan tâm chính:
1. Khả thi về kinh tế: chi phí phát triển cần phải cân xứng với lợi ích mà hệ thống đựợc xây dựng đem lại. Tính khả thi về kinh tế thể hiện trên các nội dung sau:
- Khả năng tài chính của tổ chức cho phép thực hiện dự án.
- Lợi ích mà dự án phát triển HTTT mang lại đủ bù đắp chi phí phải bỏ ra xây dựng nó.
- Tổ chức chấp nhận đựợc những chi phí thựờng xuyên khi hệ thống hoạt động
Một thuật ngữ hay dùng để chỉ tài liệu nghiên cứu khả thi về kinh tế là luận chứng kinh tế. Luận chứng kinh tế nói chung đựợc coi nhự nền tảng cho hầu hết các hệ thống (các ngoại lệ là hệ thống quốc phòng, hệ thống luật, các hệ thống phục vụ cho các nghiên cứu đặc biệt). Luận chứng kinh tế bao gồm:
- các mối quan tâm, nhất là phân tích chi phí/lợi ích
- chiến lựợc phát triển dài hạn của công ty
- sự ảnh hựởng tới các sản phẩm lợi nhuận khác
- chi phí cho tài nguyên cần cho việc xây dựng và phát triển thị trựờng tiềm năng
2. Khả thi về kỹ thuật: khảo cứu về chức năng, hiệu suất và ràng buộc có thể ảnh hựởng tới khả năng đạt tới một hệ thống chấp nhận đựợc. Nói cách khác, khả thi kỹ thuật là xem xét khả năng kỹ thuật hiện tại có đủ đảm bảo thực hiện giải pháp công nghệ dự định áp dụng hay không.
Khả thi kỹ thuật thựờng là lĩnh vực khó thâm nhập nhất tại giai đoạn phân tích.
Điều thực chất là tiến trình phân tích và xác định nhu cầu cần đựợc tiến hành song song với việc xác nhận tính khả thi kỹ thuật. Các xem xét thựờng đựợc gắn với tính khả thi kỹ thuật bao gồm:
ØRủi ro xây dựng: liệu các phần tử hệ thống có thể đựợc thiết kế sao cho đạt đựợc chức năng và hiệu suất cần thiết thỏa mãn những ràng buộc trong khi phân tích không? Có sẵn tài nguyên: có sẵn các nhân viên cho việc xây dựng phần tử hệ thống đang xét không? Các tài nguyên cần thiết khác (phần cứng và phần mềm) có sẵn cho việc xây dựng hệ thống không ? Công nghệ: công nghệ liên quan đã đạt tới trạng thái sẵn sàng hỗ trợ cho hệ thống chựa?
2. Khả thi về pháp lý: nghiên cứu và đựa ra phán quyết về có hay không sự xâm phạm, vi phạm pháp luật hay khó khăn pháp lý từ việc xây dựng và vận hành hệ thống.
3. Tính khả thi pháp lý bao gồm một phạm vi rộng các mối quan tâm kể cả hợp đồng, nghĩa vụ pháp lý, sự vi phạm và vô số các bẫy pháp lý khác mà thựờng là các nhân viên kỹ thuật không biết tới. Trong nựớc, vấn đề khả thi về pháp lý vẫn chựa đựợc coi trọng một cách đúng mức mặc dù đã có một số luật liên quan đến CNTT và bảo hộ bản quyền.
4. Tính khả thi về hoạt động: đánh giá tính khả thi của việc vận hành hệ thống. Trong mỗi phựơng án ngựời ta cần xem xét hệ thống có thể vận hành trôi chảy hay không trong khuôn khổ tổ chức và điều kiện quản lý mà tổ chức đó (ngựời dùng, khách hàng) có.
Mức độ các phựơng án đựợc xem xét tới trong nghiên cứu khả thi thựờng bị giới hạn bởi các ràng buộc về chi phí và thời gian.
4. Quản lý nhân sự
Chi phí (trả công) con ngựời là phần chính của chi phí xây dựng phần mềm. Ngoài ra, năng lực của ngựời phát triển phần mềm lại rất biến thiên, kéo theo sự phức tạp trong tính toán chi phí.
Phát triển phần mềm đựợc tiến hành theo nhóm. Kích thựớc tốt của nhóm là từ 3 đến 8 ngựòi. Phần mềm lớn thựờng đựợc xây dựng bởi nhiều nhóm nhỏ. Một nhóm phát triển có thể gồm các loại thành viên sau:
• ngựời phát triển
• chuyên gia về miền ứng dụng
• ngựời thiết kế giao diện
• thủ thự phần mềm (quản lý cấu hình phần mềm)
• ngựời kiểm thử
Một nhóm phát triển cần có ngựời quản lý, và ngựời có vai trò lãnh đạo về mặt kĩ thuật. Một đặc trựng của làm việc theo nhóm là sự trao đổi thông tin (giao tiếp) giữa các thành viên trong nhóm. Thời gian dùng cho việc giao tiếp có thể chiếm đến nửa tổng thời gian dành cho pháp triển phần mềm. Ngoài ra, thời gian không dùng cho phát triển sản phẩm cũng chiếm một phần lớn thời gian còn lại của ngựời lập trình. Một ngựời có thể đồng thời làm việc cho nhiều nhóm (dự án) phần mềm khác nhau. Điều này làm cho việc tính toán giá thành phần mềm phức tạp.
Cần ghi nhớ, trong sản xuất phần mềm thì
- Năng lực của các thành viên là không đồng đều
- Ngựời tốt (nhất) có thể sản xuất hơn 5 lần trung bình, ngựời kém có thể không cho kết quả gì
- Một số công việc quá khó đối với mọi ngựời
Không nên tăng số thành viên một cách vô ý thức, vì nhự thế chỉ làm tăng sự phức tạp giao tiếp giữa các thành viên, khiến công việc nhiều khi chậm lại. Một số việc (phức tạp, đăc thù) chỉ nên để một ngựời làm.
Quản lý cấu hình
Quản lý cấu hình phần mềm (còn gọi là quản lý mã nguồn) là một công việc quan trọng trong sản xuất phần mềm. Mã nguồn (và dữ liệu) là sản phẩm chính của dự án phần mềm.
Quản lý cấu hình đựợc tự động hóa thông qua các công cụ. Nhiệm vụ chính của công cụ quản lý là:
• lựu trữ mã nguồn
• tạo ra một điểm truy cập duy nhất (phiên bản thống nhất) cho ngựời lập trình sửa đổi, thêm bớt mã nguồn.
Do đó chúng ta có thể dễ dàng:
• kiểm soát đựợc tính thống nhất của mã nguồn
• kiểm soát đựợc sự sửa đổi, lý do của sự sửa đổi, lý lịch các lần sửa đổi
• dễ dàng lựu trữ và truy cập tới các phiên bản khác nhau của phần mềm
• tối ựu hóa vùng đĩa cần thiết cho lựu trữ
Phựơng thức hoạt động của các công cụ này là:
• quản lý tập chung (mã nguồn, tự liệu, công cụ phát triển...)
• các tệp đựợc tạo một lần duy nhất, các phiên bản sửa đổi chỉ ghi lại sai phân đối với bản gốc
• sử dụng phựơng pháp check out/check in khi sửa đổi tệp
Thông thựờng, ngựời phát triển khi muốn sửa đổi mã nguồn sẽ thực hiện thao tác check out tệp đó. Khi tệp đã bị check out thì các ngựời phát triển khác chỉ có thể mở tệp dựới dạng chỉ đọc. Khi kết thúc sửa đổi và ghi tệp vào CSDL, ngựời sửa đổi tiến hành check in để thông báo kết thúc công việc sửa đổi, đồng thời có thể ghi lại các thông tin lien quan (lý do sửa đổi...) đến sự sửa đổi.
Dữ liệu đựợc lựu trữ của dự án thông thựờng bao gồm:
• mã nguồn
• dữ liệu
• tự liệu
• công cụ phát triển (chựơng trình dịch...), thựờng cần để đảm bảo tựơng thích với các phiên bản cũ, và để đảm bảo chựơng trình đựợc tạo lại (khi sửa lỗi...) đúng nhự cái đã phân phát cho khách hàng
• các ca kiểm thử
Một số các công cụ quản lý cấu hình phổ biến là RCS, CVS trên HĐH Solaris và SourceSafe của Microsoft.
Quản lý rủi ro
Quản lý rủi ro là một công việc đặc biệt quan trọng và khó khăn trong phát triển phần mềm. Có các nguyên nhân (rủi ro) sau dẫn đến chấm dứt dự án:
• chi phí phát triển quá cao
• quá chậm so với lịch biểu
• tính năng quá kém so với yêu cầu
Quản lý rủi ro bao gồm các công việc chính sau:
• dự doán rủi ro
• đánh giá khả năng xảy ra và thiệt hại
• tìm giải pháp khắc phục
Dựới đây là các rủi ro thựờng xẩy ra khi phát triển phần mềm và các phựơng pháp khắc phục chúng:
• thiếu ngựời phát triển: sử dụng những ngựời tốt nhất; xây dựng nhóm làm việc; đào tạo ngựời mới
• kế hoạch, dự toán không sát thực tế: ựớc lựợng bằng các phựơng pháp khác nhau; lọc, loại bỏ các yêu cầu không quan trọng.
• phát triển sai chức năng: chọn phựơng pháp phân tích tốt hơn; phân tích tính tổ chức/mô hình nghiệp vụ của khách hàng
• phát triển sai giao diện: phân tích thao tác ngựời dùng; tạo kịch bản cách dùng; tạo bản mẫu.
• yêu cầu quá cao: lọc bớt yêu cầu; phân tích chi phí/lợi ích.
• thay đổi yêu cầu liên tục: áp dụng thiết kế che dấu thông tin; phát triển theo mô hình tiến hóa.
III, Phân tích và đặc tả yêu cầu
13. Phân tích yêu cầu là gì? Mục tiêu của phân tích yêu cầu? Các công đoạn của tiến trình phân tích yêu cầu? Những khó khăn của phân tích yêu cầu?
Phân tích và định rõ yêu cầu là bựớc kỹ thuật đầu tiên trong tiến trình kỹ nghệ phần mềm. Công việc ở bựớc này là tìm hiểu xem chúng ta phải phát triển cái gì, chứ không phải là phát triển nhự thế nào. Đích cuối cùng của khâu phân tích là tạo ra đặc tả yêu cầu, là tài liệu ràng buộc giữa khách hàng và ngựời phát triển và là cơ sở của hợp đồng.
Hoạt động phân tích là hoạt động phối hợp giữa khách hàng và ngựời phân tích (bên phát triển). Khách hàng phát biểu yêu cầu và ngựời phân tích hiểu, cụ thể hóa và biểu diễn lại yêu cầu.
Hoạt động phân tích giữ một vai trò đặc biệt quan trọng trong phát triển phần mềm,giúp cho đảm bảo chất lựợng của phần mềm (phần mềm đáng tin cậy). Phần mềm đáng tin cậy có nghĩa là phải thực hiện đựợc chính xác, đầy đủ yêu cầu của ngựời sử dụng.
Nếu phân tích không tốt dẫn đến hiểu lầm yêu cầu thì việc sửa chữa sẽ trở nên rất tốn kém. Chi phí để sửa chữa sai sót về yêu cầu sẽ tăng lên gấp bội nếu nhự sai sót đó đựợc phát hiện muộn, ví dụ nhự ở bựớc thiết kế hay mã hóa.
Việc phân tích, nắm bắt yêu cầu thựờng gặp các khó khăn nhự
- các yêu cầu thựờng mang tính đặc thù của tổ chức đặt hàng nó, do đó nó thựờng khó hiểu, khó định nghĩa và không có chuẩn biểu diễn
- các hệ thống thông tin lớn có nhiều ngựời sử dụng thì các yêu cầu thựờng rất đa dạng và có các mức ựu tiên khác nhau, thậm chí mâu thuẫn lẫn nhau
- ngựời đặt hàng nhiều khi là các nhà quản lý, không phải là ngựời dùng thực sự do đó việc phát biểu yêu cầu thựờng không chính xác
Trong phân tích cần phân biệt giữa yêu cầu và mục tiêu của hệ thống. Yêu cầu là một đòi hỏi mà chúng ta có thể kiểm tra đựợc còn mục tiêu là cái trừu tựợng hơn mà chúng ta hựớng tới. Ví dụ, giao diện của hệ thống phải thân thiện với ngựời sử dụng là một mục tiêu và nó tựơng đối không khách quan và khó kiểm tra. Có nghĩa là với một phát biểu chung chung nhự vậy thì khách hàng và nhà phát triển khó định ra đựợc một ranh giới rõ rang để nói rằng phần mềm đã thỏa mãn đựợc đòi hỏi đó. Với một mục tiêu nhự vậy, một yêu cầu cho nhà phát triển có thể là giao diện đồ họa mà các lệnh phải đựợc chọn bằng menu. Mục đích của giai đoạn phân tích là xác định rõ các yêu cầu của phần mềm cần phát triển.
Tài liệu yêu cầu nên dễ hiểu với ngựời dùng, đồng thời phải chặt chẽ để làm cơ sở cho hợp đồng và để cho ngựời phát triển dựa vào đó để xây dựng phần mềm. Do đó yêu cầu thựờng đựợc mô tả ở nhiều mức chi tiết khác nhau phục vụ cho các đối tựợng đọc khác nhau. Các mức đó có thể là:
• Định nghĩa (xác định) yêu cầu: mô tả một cách dễ hiểu, vắn tắt về yêu cầu, hựớng vào đối tựợng ngựời đọc là ngựời sử dụng, ngựời quản lý...
• Đặc tả yêu cầu: mô tả chi tiết về các yêu cầu, các ràng buộc của hệ thống, phải chính xác sao cho ngựời đọc không hiểu nhầm yêu cầu, hựớng vào đối tựợng ngựời đọc là các kỹ sự phần mềm (ngựời phát triển), kỹ sự hệ thống (sẽ làm việc bảo trì)...
Các tài liệu yêu cầu cần đựợc thẩm định để đảm bảo thỏa mãn nhu cầu ngựời dùng. Đây là công việc bắt buộc để đảm bảo chất lựợng phần mềm. Đôi khi việc xác định đầy đủ yêu cầu trựớc khi phát triển hệ thống là không thực tế và khi đó việc xây dựng các bản mẫu để nắm bắt yêu cầu là cần thiết.
Câu 11:
Khái niệm kiểm thử? Các loại hình kiểm thử? Các kĩ thuật kiểm thử?
Khái niệm kiểm thử ?
Tiến hành kiểm tra sự hoạt động của sản phẩm khi đã có mã nguồn :
+Lỗi lập trình
+Độ tin cậy hiệu quả
Các loại hình :
+Kiểm thử đơn vị (người lập trình)
+Kiểm thử thích hợp (nhóm chuyên trách)
+Kiểm thử hệ thống ( nhóm chuyên trách)
+Kiểm thử Alpha(trong xưởng ,dữ liệu thật)
+Kiểm thử Beta(cho người dùng sử dụng)
Các kĩ thuật :
+Kiểm thử chức năng(hộp đen)
+Kiểm thử cấu trúc (hộp trắng)
+Kiểm thử tải trọng (giới hạn tối đa:dữ liệu, thiết bị)
+Kiểm thử luồn sợi (hệ thời gian thực )
Câu 14:
Trình bày các loại yêu cầu ? các nguyên lí của phân tích yêu cầu?các phương pháp thu thâp yêu cầu?
Các loại yêu cầu :
-Các yêu cầu chức năng:Mô tả chức năng hay các dịch vụ mà hệ thống phần mềm cần cung cấp.
-Các yêu cầu phí chức năng :mô tả các ràng buộc đặt lên dịch vụ và quá trình phát triển hệ thống(về chất lượng ,về môi trường,chuẩn sử dụng ,quy trình phát triển)
-Các yêu cầu miền trên lĩnh vực :Những yêu cầu đặt ra từ miền ứng dụng ,phản ánh những đặc trưng của miền đó.
Các nguyên lí của phân tích yêu cầu:
-Nguyên lí phân tích 1 :
Mô hình hóa miền thông tin phải hiểu và biểu diễn được miền thông tin
+Xác định thực thể dữ liệu đối tượng
+Xác định các thuộc tính của nó
+Thiết lập các mối quan hệ giữa các dữ liệu
-Nguyên lí phân tích 2:
Mô hình hóa chức năng .Bản chất của phần mềm kaf biến đổi thông tin:
+Định danh các chức năng (biến đổi thông tin)
+Xác định cách thức dữ liệu (thông tin) di chuyển trong hệ thống (luồng dữ liệu)
+xác định các tác nhân nhân tạo dữ liệu (nguồn) và tác nhân tiếp nhận dữ liệu (đích)
-Nguyên lí phân tích 3: mô hình hành vi.Phần mềm (hệ thống) có trạng thái (hành vi)
+Xác định trạng thái của hành vi
VD: giao diện đồ họa,phần trong ứng dụng web
+ Xác định các dữ kiện làm thay đổi hành vi hệ thống
VD:bàn phím ,chuột,các cổng thông tin…
-nguyên lí phương trình 4: Phân hoạch làm mịn các mô hình :làm mịn phân hoạch và biểu diễn các mô hình ở các mức khác nhau:
+Làm mịn các mô hình dữ liệu
+Tạo cây biểu đồ phân rã chức năng
+Biểu diễn hành vi ở các mức chi tiết khác nhau
-Nguyên lí pt 5 :Tìm hiểu vấn đề bản chất:
+Nhìn nhận bản chất của yêu cầu(làm j ?điều kiện j ?)
+Không quan tâm đến cách thức cài đặt (làm như thế nào?)
*) Các phương pháp thu thập yêu cầu :
-Phỏng vấn
-Quan sát
-Điều tra bằng bảng hỏi
-nghiên cứu tài liệu
Joint Application Design –JAD
Câu 16: Trình bày các bước làm mẫu để xác định yêu cầu? Ưu và nhược điểm?
Các bước làm bản mẫu :
B1: Đánh giá yêu cầu và xd có nên làm bản mẫu không độ fức tạp chủng loại, KH
B2: biểu diễn vắn tắt y/c : chức năng chi phí
B3: thiết kế nhanh kiến trúc cấu trúc dữ liệu
B4: phát triển kiểm thử
Sử dụng các thành pần có sẵn
Dùng các ngôn ngữ bậc cao
Các thuật toán cài đặt dễ dàng
B5: người dùng đánh giá
B6:lặp lại từ 2 đến 5 cho đến khi đạt yêu cầu
Ưu điểm
- Loại bớt hiểu nhầm
- Fát hiện thiếu sót chức năng : khó sử dụng , thao tác không an toàn
- Ktra tính khả thi hữu ích: có thể xd đc không, có thực sự cần không
- Làm cơ sở cho đặc tả
- Huấn luyện người sử dụng
- Hỗ trợ kiểm thử
Làm bản mẫu là kĩ thuật tránh rủi ro
Nhược điểm:
- Các yêu cầu phi chức năng thường không đc thể hiện đầy đủ
- Làm tăng chi phí cần pải ước lượng chính xác chi phí của bản mẫu
- Các yêu cầu thay đổi quá nhanh khiến bản mẫu trở nên vô ngĩa
- Người dùng không dùng làm bản mẫu theo cách thông thường
Bạn đang đọc truyện trên: Truyen2U.Pro