6 mục tiêu của phương pháp luận là: • Có thể thu thập chính xác các yêu cầu dành cho một HTTT: Một phương pháp có thể giúp người dùng đặc tả các yêu cầu hoặc giúp người phát triển hệ thố
Trang 1ÔN TẬP ISD (information system development)
Chap 2:
1. Nêu 6 mục tiêu của pp luận phát triển HTTT, trong 6 mục tiêu của pp luận phát triển HTTT, mục tiêu nào là quan trọng nhất? vì sao?
6 mục tiêu của phương pháp luận là:
• Có thể thu thập chính xác các yêu cầu dành cho một HTTT: Một phương pháp có thể giúp người dùng đặc tả các yêu cầu hoặc giúp người phát triển hệ thống nghiên cứu và phát triển các yêu cầu của người dùng, nếu không thì hệ thống đưa ra sẽ không phù hợp với yêu cầu người dùng
• Có thể cung cấp được một phương pháp phát triển có hệ thống để tiến độ có thể được giám sát một cách hiệu quả: Điều khiển kiểm soát một dự án quy mô lớn là không hề dễ dàng Một dự án mà không có thời hạn có thể có chi phí khủng khiếp và các tiềm ẩn khác cho tổ chức Việc cung cấp các chốt kiểm soát và các giai đoạn xác định rõ ràng trong phương pháp nên đảm bảo rằng các kỹ thuật lập kế hoạch cho dự án được áp dụng một cách hiệu quả
• Cung cấp một hệ thống trong một khoảng thời gian thích hợp và ở một mức giá chấp nhận được Trừ khi thời gian dành cho việc dùng các kỹ thuật bao gồm các phương pháp luận được giới hạn, nếu không thì việc dành thời gian lớn để cố gắng đạt được sự hoàn hảo sẽ không bị phản đối
• Tạo ra được một hệ thống mà có thể được dẫn chứng tốt và duy trì dễ dàng: Những cần thiết cho việc sửa đổi HTTT trong tương lai là không thể tránh khỏi cũng như kết quả của những thay đổi khi tham gia vào một tổ chức và môi trường của nó Những sửa đổi này nên được tiến hành mà ảnh hưởng càng ít càng tốt lên những phần còn lại của hệ thống
• Cung cấp được các biểu hiện của bất kỳ sự thay đổi cần phải được tiến hành làm càng sớm càng tốt trong một quy trình phát triển hệ thống Một HTTT phát triển từ việc phân tích thông qua thiết kế để thực hiện, các chi phí liên quan với việc thay đổi sẽ tăng lên
Do đó, bản thay đổi mới nhất sẽ được tốt hơn
• Cung cấp được một hệ thống được những người có liên quan ưa thích: Những người có liên quan đến hệ thống, ví dụ như những bên liên quan bao gồm khách hàng, quản lý, kiểm tra viên, và người dùng Nếu một hệ thống được những bên liên quan ưa thích, nó
có nghĩa là hệ thống đó sẽ được dùng và thành công
Chap 3:
2. Điểm mạnh và yếu của chu trình phát triển truyền thống SDLC
• Phương pháp tiếp cận hệ thống để
phát triển
• Hệ thống được lập tài liệu tốt, dễ
bảo trì
• Không đạt được yêu cầu của nhà quản lý
• Không ổn định
• Thiếu linh động
Trang 2• Cải thiện kiểm soát chất lượng và
các tiêu chuẩn
• Tập trung cho đào tạo
• Tạo điều kiện tốt để quản lý dự án
• Sự nhất quán giữa các dự án
• Sự thống nhất trên toàn hệ thống
thông tin
• Học tập và rút kinh nghiệm trong sử
dụng
• Nâng cao chất lượng sản phẩm và
quá trình
• Có vấn đề về tài liệu
• Thiếu kiểm soát
• Hệ thống không hoàn thiện
• Sự tồn đọng ứng dụng
• Khối lượng công việc cần phải duy trì
• Vấn đề với cách tiếp cận lý tưởng
• Tầm quan trọng của suy nghĩ cứng
• Giả định về phát triển green-field
3. Bạn sẽ sử dụng SDLC để phát triển 1 ứng dụng nhỏ chạy trên 1 PC? Bạn sẽ
chỉnh sửa nó lại theo cách nào?
- Phân tích tính khả thi: xem xét chi phí, thời gian xây dựng và trình độ của bản thân có đủ để
thực hiện dự án nhỏ này hay không? Sau khi xây dựng xong thì ứng dụng này có thể đáp ứng các yêu cầu của người dùng k? Khả năng thành công là bao nhiêu?
- Phân tích các yêu cầu và đặt tính kỹ thuật:
Xác định yêu cầu của người dùng đối với ứng dụng mới?
Phân tích phạm vi sử dụng của ứng dụng này?
Phân tích các đặt tính kĩ thuật:
• Đối với hệ thống: mô tả chi tiết các bước xem xét hệ thống: cấu hình phần cứng, phần mềm hệ thống, các yếu tố kĩ thuật khác
Mô tả quy trình cài đặt hệ thống
Mô tả các phương pháp xác định lỗi cài đặt và cách sử dụng
• Đối với Ứng dụng mới:
Mô tả chi tiết các bước cài đặt ứng dụng
Mô tả các tham số cài đặt
Mô tả các phương pháp xác định lỗi cài đặt
- Thiết kế:
• Sử dụng mô hình đồ họa của hệ thống để biểu diễn các yêu cầu của người dùng về dữ liệu, các quy trình, giao diện và để đơn giản hóa việc cải thiện sự truyền thông tin giữa các người dùng
• Kỹ thuật sẽ được sử dụng như thế nào để xây dựng hệ thống về mặt dữ liệu, các quy trình và giao diện
- Mã hóa: thiết kế phải được dịch sang 1 dang ngôn ngữ có thể đọc/hiểu được đây lf giai đoạn
thực hiện nhiệm vụ này Sử dụng các công cụ lập trình như biên dịch, phiên dịch, gỡ rối,… được dử dụng để mã hóa Sử dụng các ngôn ngữ lập trình C/C++, pascal, java được sử dụng để viết mã…
- Kiểm thử: Sau khi mã được tạo ra, ta sd các pp kiểm thử khác nhau có thể đc sd để làm sáng
tỏ những lỗi có thể xảy ra
Sau khi đã đc ktra 1 cách thích hợp và đc chấp thuận, nó sẽ ddcj đưa vào sd thực tế
- Bảo trì: duy trì và nâng cấp phần mềm để đối phó với các vấn đề mới đc phát hiện hoặc yêu
cầu mới có thể tốn nhiều thời gian hơn so với việc phát triển ban đầu của ứng dụng
Trang 3Các cách sửa đổi: ứng dụng cần phải đc xd 1 cách mềm dẻo để có thể dễ dàng thay đổi.
Sử dụng các phần mềm sửa lỗi
Sử dụng các công cụ lập trình
Chap 4:
4. Hãy cho biết tại sao BPR (business process re-engineering) đc chỉnh sửa lại theo hướng mềm hơn? Bạn có nghĩ rằng việc thay đổi này sẽ làm giảm tiềm năng của nó?
BPR là 1 quy trình xác định những gì mà tổ chức nên làm, làm thế nào và những gì có liên quan, và chỉnh sửa lại hệ thống hiện tại nó là 1 cách tiếp cận triệt và lôi kéo theo " tái tạo kinh doanh – không phải cải thiện/nâng cao hay sửa đổi việc kinh doanh”
Lý do BPR được chỉnh sửa lại theo hướng mềm hơn là vì phiên bản BPR truyền thống quá mạnh mẽ và mang lại rủi ro cao Mục tiêu chính của doanh nghiệp khi áp dụng BPR là để tái
cơ cấu lại tổ chức, đầu ra của BPR là gồm:
• Làm phẳng cấu trúc của tổ chức
• Tăng sự tập trung vào khách hàng
• Cải thiện khả năng làm việc nhóm, hướng đến sự hiểu biết rõ hơn về vai trò của những người khác
Tuy nhiên mặc cho những yếu tố quan trọng đó, đã có nhiều báo cáo về sự thất bại khi doanh nghiệp áp dụng BPR xuất hiện Tỉ lệ thất bại khi áp dụng BPR khá cao khoảng 50-70%, sự thất bại này được lý giải phần lớn là do các công ty và các nhà quản lý không đủ triệt để Những nhà phân tích nhấn mạnh rằng những nhà quản lý cấp cao không đủ tham vọng cho những thay đổi triệt để và họ thiếu bản lĩnh để lĩnh hội đầy đủ BPR Hơn nữa, họ chỉ ra rằng các nhà quản
lý đã hiểu sai về mức độ thay đổi cần thiết, điều này không chỉ ở trong quy trình kinh doanh
mà còn ở trong hành vi quản lý và cấu trúc tổ chức Bên cạnh đó, sự thiếu hụt nguồn lực, thiếu
sự hỗ trợ từ các quản lý cấp cao cũng như thời gian mà nó cần để đạt được kết quả đã dẫn tới
áp lực từ bỏ chương trình BPR Những yếu tố này đã dẫn đến những phản ứng dữ dội chống lại BPR đòi hỏi nó phải được tinh chỉnh theo hướng mềm hơn
Việc mềm hóa BPR đã làm giảm tiềm năng của nó Nếu như BPR bản truyền thống tập trung thay đổi, tái cơ cấu toàn bộ doanh nghiệp một cách mạnh mẽ trong thời gian ngắn và đem lại
sự khác biệt lớn cho tổ chức thì bản BPR “mềm hóa” có xu hướng từ từ và thay đổi từng phần nhỏ, dẫn đến sự ít khác biệt hơn và trong bối cảnh các DN cạnh tranh gay gắt thì việc thay đổi từng phần nhỏ trong thời gian dài này của BPR mới sẽ khiến DN áp dụng nó ít có sự mới mẻ hơn và ít tố chất cạnh tranh hơn nhưng lại an toàn hơn bản BPR cũ
Chap 5:
Trang 45. Earl cho rằng tiếp cận đơn hướng để xác định và tích hợp hệ thống thông tin với chiến lược kinh doanh sẽ không thành công Hãy cho biết tiếp cận đa hướng của Earl.
Một phương pháp tiếp cận đáng quan tâm khác nhằm đưa ra chiến lược hệ thống thông tin và sự kết hợp giữa việc phát triển hệ thống thông tin và yêu cầu trong kinh doanh được đưa ra bởi Earl Phương pháp này dựa trên cơ sở là không có một phương pháp tiếp cận nào có thể hy vọng thành công Earl đưa ra một phương pháp kết hợp một số lượng lớn các yếu tố và kỹ thuật khác nhau, bao gồm phân tích từ-trên-xuống và từ-dưới-lên Những yếu tố thông dụng thì không mới nhưng chúng được tập hợp lại vào một phương pháp tiếp cận được cho là toàn diện và hiệu quả
Yếu tố đầu tiên của mô hình của Earl là phân tích từ trên xuống trong doanh nghiệp Mục tiêu của nó dẫn đến sự chứng minh cho vai trò tiềm năng của hệ thống thông tin Đây là một hoạt động kinh doanh dẫn từ trên xuống, trong đó người IT sẽ đóng vai trò hỗ trợ chứ không phải theo chiều ngược lại Sẽ là dễ đạt được khi sử dụng các kỹ thuật vững chắc như CSFs, phân tích SWOt, và mô hình năm lực lượng của Porter để giúp đánh giá vị trí cạnh tranh, yếu tố công nghiệp, sức mạnh của đối thủ cạnh tranh.v…v nhằm sử dụng hệ thống thông tin để xác định lợi thế và nhược điểm.
Yếu tố thứ hai trong mô hình của Earl là phân tích hệ thống của tổ chức từ dưới lên Đây là một yếu tố quan trọng của mô hình bởi vì, như ở rất nhiều phương pháp tiếp cận khác nhằm xây dựng chiến lược, hệ thống hiện tại không được chấp nhận và trường hợp “green-field” được giả định.Điều này thông thường là không thực tế và thường dẫn đến sự thất bại vì hệ thống hiện có của tổ chức đã bị bỏ qua Phân tích bao gồm đánh giá thế mạnh và điểm yếu của việc cung cấp một hệ thống thông tin cũng như đánh giá hệ thống hiện tại dựa trên cơ sở đầu tiên là sự đóng góp về mặt kinh doanh và giá trị đối với người sử dụng, thứ hai là chất lượng kỹ thuật.
Trang 56. Hãy chọn ra 1 công ty hay 1 phòng ban của 1 trường Đại học, bạn sẽ xác định các yêu cầu của 1 HTTT mới bằng cách nào?
Các yêu cầu khi xây dựng 1 HTTT mới bao gồm yêu cầu chức năng (function requirements)
và yêu cầu phi chức năng (non – function requirements)
Các yêu cầu chức năng bao gồm việc xác định các quy trình nghiệp vụ, các dữ liệu đầu vào và kết quả đầu ra của hệ thống, xác định các dữ liệu/thông tin cần được quản lý
Các yêu cầu phi chức năng bao gồm các yêu cầu làm thế nào mà hệ thống hỗ trợ các yêu cầu chức năng như: bảo mật, giao diện, tính tiện lợi…
Bài làm:
Các bước thực hiện phân tích yêu cầu:
1. Tiên đoán (khảo sát sơ bộ)
2. Nghiên cứu khảo sát (lên kế hoạch khảo sát chi tiết)
3. Phân tích (có nhận xét của chuyên viên)
4. Kết quả: Hồ sơ phân tích hiện trạng
1. Tiên đoán: (sơ bộ)
Đối với công việc tiên đoán chuyên viên phân tích cần giải đáp được một số câu hỏi như sau:
- Hệ thống thông tin mới bao gồm cái gì? / Hệthống thông tin hiện tại đang bao gồm nội dung gì? Và tương lai cần thêm nội dung gì? Những thông tin gì? Lấy ở đâu? Lúc nào? Hiện tại đang ởdưới dạng nào? Ai đang chịu trách nhiệm? Gốc phát sinh thuộc thông tin? Được phát sinh lúc nào?, …
Trang 6- Kết quả:
Những con người/bộphận -> cần đi để làm việc với họ
Danh sách những tài liệu/ chứng từ cần tìm hiểu
2. Nghiên cứu khả thi: lên kế hoạch khảo sát chi tiết
- Khảo sát, xác định nguồn thông tin: nội bộ hay bên ngoài môi trường
- Khảo sát quy trình nghiệp vụ cơ bản
Mục đích qui trình? : Có bao nhiêu bước? Đi qua đâu (bộ phận nào?) Bởi ai? Bao lâu? Tần
suất? Ai dùng thông tin kết quả? Dùng ntn?
- Cuối cùng là đánh giá thuộc từng bộ phận nghiệp vụ liên quan đến công việc của họ
3. Phân tích:(có nhận xét của chuyên viên)
- Phân tích hiệu quả và đánh giá tính khảthi của hệ thống:
- Khả thi về mặt kỹ thuật
- Khả thi về tác vụ
- Khả thi về kinh tế
Đưa ra một số các giải pháp để so sánh, đánh giá và cuối cùng sẽ chọn một giải pháp tối ưu nhất và có thể chấp nhận được
• Các kỹ thuật thu thập thông tin:
- Phỏng vấn
- Lập bảng câu hỏi (viết)
- Nghiên cứu tài liệu
- Quan sát hiện trường
o Phỏng vấn
Phương thức phỏng vấn sẽ được thực hiện trực tiếp với người tham gia vào hệ thống
Đối tượng phỏng vấn: Cá nhân Bộphận/tổ
Phương thức phỏng vấn: Tựdo: hỏi đâu trả lời đó
Có hướng dẫn: hướng người được phỏng vấn theo mục tiêu chính…
Trước khi phỏng vấn: nhóm phân tích cung cấp cho lãnh đạo cao nhất trong tổ chức danh sách bộ phận, những cá nhân và thời gian sẽ thực hiện phỏng vấn đểsắp xếp kế hoạch làm việc
Những thông tin liên quan đến kế hoạch phỏng vấn cần phải được thông báo trước như:
Danh sách người + bộ phận sẽ phỏng vấn
Lịch làm việc (không được áp đặt cho khách hàng)
Xác định trở lại vị trí của những người mà mình phải làm việc trong cơ cấu tổ chức và những nhiệm vụcủa họ
Trang 7Sau khi phỏng vấn:
Tóm tắt, nhắc lại nội dung sau buổi phỏng vấn với mục tiêu để kiểm tra, hệthống hóa nội dung thu thập được sau buổi phỏng vấn Nếu cần thiết có thểlập biên bản phỏng vấn
o Lập bảng câu hỏi:
Bảng câu hỏi sẽ được nhóm phân tích chuẩn bị trước, sau khi chuẩn bi xong bảng câu hỏi có thể gởi cho những cá nhân/ bộ phận có liên quan để họ trả lời
Khi sử dụng bảng câu hỏi cần: thử nghiệm trong đối tượng hẹp, sau đó triển khai ra đối tượng rộng
o Nghiên cứu tài liệu
- Qui định nội bộ (thường tốt trong doanh nghiệp có ISO)
- Chủ trương của đơn vị/doanh nghiệp như thế nào?
- Những qui định bất thành văn trong đơn vị/doanh nghiệp sửdụng HTTT
o Quan sát hiện trường
Quan sát hiện trường bằng cách tham gia trực tiếp vào một bước trong qui trình hoặc cảqui trình nghiệp vụ đểcó thểghi nhận nắm bắt được những thông tin cần thiết
4. Kết quả: Hồ sơ phân tích hiện trạng
Các kỹ thuật phân tích
- Các kỹ thuật phân tích có thể dựa trên các công cụ như:
- Cây quyết định (giống nhưuser case)
- Bảng quyết định
- Sơ đồ lưu chuyển thông tin và chứng từ
- Sơ đồ tổ chức
⇒Kết quả cuối cùng của giai đoạn phân tích yêu cầu là bộ hồ sơ phân tích hiện trạng
Xác định các yêu cầu:
1. Các yêu cầu quá trính truyền thống
2. Các vấn đề thực tế
3. Các yêu cầu thay đổi và mở rộng
4. Các yêu cầu không thể biết
5. Các yêu cầu phi chức năng
Chap 6:
7. Tại sao mô hình hóa quy trình và mô hình hóa dữ liệu lại tách rời nhau? Còn điều gì nên đc mô hình nữa trong 1 HTTT?
Mô hình hóa quy trình Process Modelling: gồm 2 mô hình là mô hình luồng DL (data flow diagram) và tiếng anh có cấu trúc (structured English)
Mô hình hóa dữ liệu là gì?
Trang 8Mô hình hóa dữ liệu là quá trình tạo ra mọt mô hình khái niệm của các đối tượng dữ liệu và làm thế nào các đối tượng dữ liệu liên kết với nhau trong một CSDL Mô hình dữ liệu tập trung vào cách các đối tượng dữ liệu được tổ chức hơn về hoạt động được thực hiện trên dữ liệu
Có 2 phương pháp chính được sử dụng để mô hình hóa dữ liệu được gọi là các thực thể- mô hình ER và mô hình đối tượng Sử dụng rộng rãi nhất trong số này là mô hình ER Mô hình dữ liệu được tạo ra bằng cách sử dụng các yêu cầu của CSDL bằng cách xem xét các tài liệu hiện
có và phỏng vấn người dùng của hệ thống
Mô hình hóa quy trình là gì?
Mô hình quá trình hoặc cụ thể mô hình hóa quá trình kinh doanh(BPM) liên quan đến quá trình đại diện của một doanh nghiệp mà các quá trình hiện tại có thể được phân tích để nâng cao chất lượng và hiệu quả BPM nói chung là theo sơ đồ của chuỗi các hoạt động được thực hiện trong một tổ chức Nó sẽ hiển thị các sự kiện, hành động và các điểm kết nối từ đầu đến cuối của chuỗi Kỹ thuật cơ bản là phân rã chứcnăng
Có 2 kỹ thuật mô hình hóa quy trình là sơ đồ luồng dữ liệu và tiếng anh cấu trúc
Sự khác biệt giữa mô hình hóa đối tượng và mô hình hóa quy trình là gì?
Mô hình dữ liệu đại diện cho các đối tượng dữ liệu và tương tác giữa các đối tượng dữ liệu trong một tổ chức, trongkhi các mô hình quy trình là theo sơ đồ của một chuỗi các hoạt động trong một tổ chức Mô hình dữ liệu có thể được xem như là một phần của mô hình quá trình kinh doanh, xác định như thế nào thông tin trong tổ chức nên được lưu trữ một cách hiệu quả
để cải thiện hiệu suất tổng thể Trong một tổ chức điển hình có sự tương tác quan trọng giữa
mô hình dữ liệu và các mô hình quy trình kinh doanh Việc phân tách giữa thiết kế luận lý và vật lý là vấn đề quan trọng Nó đem đến một mức độc lập dữ liệu dữ liệu thì thường ổn định hơn quy trình Ví dụ như trong trường đại học, thì những dữ liệu liên quan đến sinh viên thì ổn định những nghiệp vụ, những quy trình trong trường đại học đối với sinh viên Sinh viên sẽ có tên, địa chỉ, mssv, còn quy trình ví dụ như quy trình đăng kí thì có thể thay đổi Nếu không tách biệt hai cái đó Mỗi khi một phần tử riêng lẻ thay đổi hay có sự thay đổi trong một tiến trình xử lý thì kéo theo phải thay đổi các tập tin dữ liệu tương ứng Việc tổ hợp các tập tin dữ liệu chuyên biệt cũng rất khó khăn, vì mỗi tập tin mang tên và định dạng dữ liệu khác nhau Cách tiếp cận này tạo ra sự dư thừa dữ liệu, hao phí qua nhiều công sức cho việc thu thập và tổ chức dữ liệu,
và các dữ liệu sử dụng kém hiệu quả do không thể chia sẻ giữa các ứng dụng với nhau vì vậy
mô hình hóa quy trình cần tách biệt với mô hình hóa dữ liệu
8. Tại sao bạn nghĩ mô hình hóa đối tượng lại bao hàm nhiều hơn ng dùng so với mô hình hóa DL và quy trình?
Sự phát triển của hướng đối tượng khác so với những mô hình khác, chẳng hạn như mô hình hóa dữ liệu và quy trình đã được mô tả ở những phần trước Rõ ràng nó bao hàm mô hình hóa
Trang 9dữ liệu và quy trình, vì đây là những nguyên tắc cơ bản của của hệ thống, nhưng nó theo một cách hoàn toàn khác nhau Nó không xử lý dữ liệu và các quá trình riêng biệt nhưng kết hợp hoặc đóng gói chúng thành một đối tượng
Một đối tượng đại diện cho một cái gì đó trong thế giới thực, ví dụ một đối tượng đại diện cho một chiếc xe hơi, trong một ứng dụng cho thuê xe Nó có dữ liệu, chẳng hạn như các nhà sản xuất, mô hình, màu sắc, số chỗ ngồi, đi lại, v.v… Nó cũng có quá trình hay hành động, chẳng hạn như đi về phía trước, đi ngược, phanh, tăng tốc, v.v…
Mô hình hướng đối tượng có liên quan với đại diện các đối tượng, bao gồm cả dữ liệu và quy trình của chúng, và sự tương tác của các đối tượng, trong một hệ thống
Phương pháp tiếp cận hướng đối tượng đại diện cho dữ liệu, quy trình, con người, và như vậy, tất cả các đối tượng
Chap 7:
9. So sánh và phân biệt các pp tiếp cận khác nhau cho việc phát triển HTTT (giữa evolutionary, prototype, rad, agile Web – base) với SDLC
PHƯƠNG PHÁP THÁC NƯỚC SDLC: gồm 7 bước, bước trước là cơ sở cho bước
sau, bước sau chỉ có thể được thực hiện khi bước trước đó đã được hoàn tất 7 bước đó là:
− Khởi tạo
− Đánh giá khả thi
− Phân tích
− Thiết kế
− Xây dựng
− Chuyển giao
− Bảo trì và đánh giá
Pp SDLC là một pp khá cứng nhắc, mô tả quá trình sàng lọc qua từng bước với pp này, tồn tại nguy cơ tích lỗi qua từng bước và khó giải quyết lỗi khi phát hiện nếu đã đi qua nhiều bước Với pp này, HT được lập tài liệu tốt, phân rã công việc rõ ràng, tạo đkiện tốt để quản lý dự án Nhưng điểm yếu là việc thiết kế dựa trên yếu tố đầu ra có sẵn dẫn đến việc thiếu linh hoạt, khó kiểm soát lỗi, khó bảo trì, và phụ thuộc lớn vào giả định khi ptriển HT nên khó điều chỉnh khi
có biến động từ môi trường
PHÁT TRIỂN ỨNG DỤNG NHANH RAPID APPLICATIONS DEVELOPMENT RAD:
Pp phát triển tiến hóa là 1 vòng lặp đi lặp lại các bước cho đến khi hoàn thiện HT bao gồm các bước Lắng nghe yêu cầu từ KH xây dựng HT Kiểm tra và quay lại lắng nghe ý kiến KH cho đến khi HT được hoàn chỉnh
Pp RAD giải quyết được vấn đề cứng nhắc của pp thác nước truyền thống Trong RAD, có sự tham gia tích cực, trực tiếp của ng dùng trong quá trình ptriển HT và tăng tốc độ ptriển so với
Trang 10pp truyền thống Ngoài ra, các lỗi phát sinh có thể đc kiểm soát dễ dàng hơn thay vì tích tụ như SDLC Dễ dàng tính toán các chi phí cho dự án
Nhược điểm của RAD là không phù hợp cho các dự án lớn và phức tạp, bên cạnh đó, cần có sự liên kết chặt chẽ giữa các bên cho việc ptriển HT
PHÁT TRIỂN TIẾN HÓA EVOLUTIONARY DEVELOPMENT
Là một phương pháp lặp đi lặp lại và gia tăng để phát triển phần mềm
Khuyết điểm của pp này là:
− Quy trình thì không nhìn thấy rõ được: Các nhà quản lý cần phân phối thường xuyên để đo lường sự tiến bộ Nó không kinh tế trong việc làm ra các hồ sơ cho phần mềm
− Phần mềm thường dược cấu trúc nghèo nàn: Sự thay đổi liên tục dễ làm đổ vỡ cấu trúc của phần mềm, tạo ra sự khó khăn và tốn phí
− Thường đòi hỏi những kỹ năng đặc biệt: Hầu hết các hệ thống khả dĩ theo cách này được tiến hành bởi các nhóm nhỏ có kỹ năng cao cũng như các cá nhân phải năng động
Mô hình này thích hợp với:
− Phát triển các loại phần mềm tương đối nhỏ
− Phát triển các loại phần mềm có đời sống tương đối ngắn
TẠO MẪU PROTOTYPING
Trong đó, qui trình được bắt đầu bằng việc thu thập yêu cầu với sự có mặt của đại diện của cả phía phát triển lẫn khách hàng nhằm định ra mục tiêu
tổng thể của hệ thống phần mềm sau này, đồng thời ghi nhận tất cả những yêu cầu có thể biết được và sơ luợc những nhóm yêu cầu nào cần phải được làm rõ Sau đó, thực hiện thiết kế nhanh tập trung chuyển tải những khía cạnh thông qua prototype để khách hàng có thể hình dung, đánh giá giúp hoàn chỉnh yêu cầu cho toàn hệ thống phần mềm Việc này không những giúp tinh chỉnh yêu cầu, mà đồng thời giúp cho đội ngũ phát triển thông hiểu hơn những gì cần được phát triển Tiếp theo sau giai đoạn làm prototype này có thể là một chu trình theo mô hình waterfall hay cũng có thể là mô hình khác
Chú ý, prototype thường được làm thật nhanh trong thời gian ngắn nên không được xây dựng trên cùng môi trường và công cụ phát triển của giai đoạn xây dựng phần mềm thực sự sau này Prototype không đặt ra mục tiêu tái sử dụng cho giai đoạn phát triển thực sự sau đó
PHÁT TRIỂN LINH HOẠT AGILE DEVELOPMENT