Lập trình có cấu trúc: Thuật ngữ này được đặt ra từ cuối những năm 60 và có nghĩa là lập trình mà không dùng lệnh goto, lập trình chỉ dùng các vòng lặp while và các phát biểu if để xây [r]
Tầm quan trọng và sự tiến hóa của phần mềm
Tiến hóa của phần mềm
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):
Trong giai đoạn này, phần cứng máy tính liên tục thay đổi, với số lượng máy tính rất hạn chế Đặc biệt, mỗi máy thường được đặt hàng theo yêu cầu cho một ứng dụng cụ thể.
Phương thức chính trong xử lý dữ liệu là xử lý theo lô (batch), cho phép "gói" các chương trình sử dụng kết quả của nhau thành một khối, từ đó tăng tốc độ thực hiện.
Trong giai đoạn này, lập trình máy tính được xem như một nghệ thuật mang tính "bản năng", thiếu phương pháp hệ thống Quá trình phát triển phần mềm chưa được quản lý một cách hiệu quả.
Môi trường lập trình mang tính cá nhân, với thiết kế và tiến trình phần mềm thường không rõ ràng và thiếu tài liệu Sản xuất phần mềm diễn ra theo hình thức đơn chiếc và theo đơn đặt hàng Lập trình viên không chỉ là người phát triển mà còn đảm nhiệm cả việc bảo trì và sửa lỗi Thời kỳ này kéo dài từ những năm 1960 đến giữa những năm 1970.
Sự xuất hiện của các hệ thống đa nhiệm và đa người sử dụng như Multics và Unix đã tạo ra khái niệm mới về tương tác người máy, mở ra một thế giới mới cho các ứng dụng và yêu cầu nâng cao về độ tinh vi cho cả phần mềm lẫn phần cứng.
Nhiều hệ thống thời gian thực hiện nay có khả năng thu thập, phân tích và biến đổi dữ liệu từ nhiều nguồn khác nhau, đồng thời phản ứng và tạo ra đầu ra trong một khoảng thời gian nhất định.
- 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ự phát triển mạnh mẽ của các hệ thống máy tính, nhu cầu mở rộng phân phối, và sự gia tăng quy mô của phần mềm đã dẫn đến nhu cầu sửa chữa khi gặp lỗi, điều chỉnh theo yêu cầu của người dùng và thích nghi với những thay đổi trong môi trường phần mềm như phần cứng, hệ điều hành và chương trình dịch mới Công việc bảo trì phần mềm trở nên tốn kém về công sức và tài nguyên, đến mức báo động, đặc biệt trong giai đoạn từ giữa những năm 1970 đến đầu những năm 1990.
Hệ thống phân tán, với nhiều máy tính thực hiện các chức năng khác nhau và giao tiếp lẫn nhau, đã góp phần làm gia tăng quy mô và độ phức tạp của phần mềm ứng dụng.
Sự phát triển mạnh mẽ của mạng toàn cục và cục bộ cùng với liên lạc số giải thông cao đã làm gia tăng nhu cầu truy cập dữ liệu trực tuyến, từ đó tạo ra yêu cầu lớn về phát triển phần mềm quản lý dữ liệu.
Công nghệ chế tạo bộ vi xử lý đang phát triển nhanh chóng, dẫn đến sự bùng nổ của máy tính cá nhân, máy trạm và các thiết bị nhúng như robot, ô tô, thiết bị y tế và đồ điện gia dụng Sự tiến bộ này đã tạo ra nhu cầu ngày càng cao về phần mềm.
- 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 đang trở thành một phương pháp tiên tiến, nhanh chóng thay thế các cách tiếp cận phát triển phần mềm truyền thống trong nhiều lĩnh vực ứng dụng.
Sự bùng nổ của Internet đã dẫn đến sự gia tăng nhanh chóng số lượng người dùng máy tính, kéo theo nhu cầu về phần mềm ngày càng cao Điều này cũng đồng nghĩa với việc quy mô và độ phức tạp của các hệ thống phần mềm mới ngày càng gia tăng đáng kể.
Phần mềm trí tuệ nhân tạo, với các thuật toán phi số như hệ chuyên gia và mạng nơ ron nhân tạo, đã được chuyển từ môi trường 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 một cách hiệu quả.
Sự ứ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 thời gian thực là loại phần mềm có khả năng điều phối, phân tích và kiểm soát các sự kiện thế giới thực ngay lập tức khi chúng xảy ra Một ví dụ điển hình của phần mềm này là các hệ thống điều khiển thiết bị tự động Các thành phần chính của phần mềm thời gian thực bao gồm khả năng xử lý dữ liệu ngay lập tức và phản hồi nhanh chóng với các sự kiện.
- 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ụ
Phần mềm phục vụ cho các hoạt động kinh doanh và nghiệp vụ của tổ chức, doanh nghiệp, là lĩnh vực ứng dụng phần mềm lớn nhất hiện nay Điển hình là các hệ thống thông tin quản lý liên kết chặt chẽ với cơ sở dữ liệu (CSDL) và các ứng dụng tương tác, như xử lý giao dịch tại các điểm bán hàng.
- Đượ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
Kể từ khi máy tính cá nhân ra đời, đã có sự bùng nổ trong việc giải quyết các bài toán nghiệp vụ nhỏ, bao gồm xử lý văn bản, bảng tính, đồ họa và quản trị cơ sở dữ liệu 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 của trí tuệ nhân tạo bao gồm hệ chuyên gia với cơ sở tri thức, nhận dạng hình ảnh và tiếng nói, chứng minh định lý, chơi trò chơi, và mô phỏng.
Phần mềm phục vụ kỹ nghệ phần mềm bao gồm các công cụ như chương trình dịch, phần mềm gỡ rối và các công cụ hỗ trợ phân tích thiết kế (CASE) Những phần mềm này có thể được phát triể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 phần mềm nghiệp vụ, đóng vai trò quan trọng trong việc nâng cao hiệu quả phát triển phần mềm.
Khó khăn, thách thức đối với phát triển 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
Bốn thuộc tính chủ chốt mà một hệ phần mềm tốt phải có là:
Phần mềm có thể bảo trì được là yếu tố quan trọng nhất để đảm bảo tuổi thọ dài cho sản phẩm Để đạt được điều này, phần mềm cần được thiết kế với tính modun hóa cao, sử dụng ngôn ngữ lập trình bậc cao và có tài liệu đầy đủ, bao gồm phân tích, thiết kế, chú thích mã nguồn và hướng dẫn người dùng Việc bảo trì phần mềm phải thực hiện dễ dàng và tiết kiệm chi phí.
Phần mềm đáng tin cậy cần thực hiện đúng những gì người tiêu dùng mong đợi và không gặp phải nhiều lỗi hơn những gì đã được mô tả Điều này đồng nghĩa với việc phần mềm phải đáp ứng nhu cầu của người dùng Để đảm bảo tính đáng tin cậy, các nhà phát triển cần hiểu rõ yêu cầu của người dùng và thỏa mãn những yêu cầu này thông qua thiết kế và cài đặt chất lượng.
Phần mềm hiệu quả không được lãng phí tài nguyên hệ thống như bộ nhớ và bộ xử lý; nếu phần mềm chạy chậm hoặc tiêu tốn quá nhiều bộ nhớ, các chức năng cài đặt sẽ không được sử dụng Tuy nhiên, trừ các phần mềm nhúng hay thời gian thực đặc biệt, việc tối ưu hóa hiệu suất thường không được ưu tiên do yêu cầu kỹ thuật phức tạp và lập trình bằng ngôn ngữ máy, dẫn đến chi phí cao và khó khăn trong bảo trì.
Phần mềm cần phải dễ sử dụng với giao diện thân thiện, phù hợp với kiến thức của người dùng, kèm theo tài liệu hướng dẫn và tiện ích hỗ trợ Đối tượng chính của các phần mềm nghiệp vụ thường là những người không có nhiều kinh nghiệm về máy tính, vì vậy họ sẽ tránh xa những phần mềm khó học và khó sử dụng.
Tối ưu hóa đồng thời các thuộc tính như hiệu quả, tính dễ sử dụng và tính bảo trì là một thách thức lớn, do chúng có thể mâu thuẫn lẫn nhau Mối quan hệ giữa chi phí cải tiến và hiệu quả không phải lúc nào cũng tuyến tính, vì vậy một cải thiện nhỏ trong bất kỳ thuộc tính nào có thể tốn kém đáng kể.
Một trong những thách thức lớn trong phát triển phần mềm là việc định lượng các thuộc tính và chất lượng của nó, do thiếu các tiêu chuẩn và độ đo cụ thể Giá cả cũng là yếu tố quan trọng cần xem xét khi xây dựng phần mềm; chúng ta có thể tạo ra những sản phẩm phức tạp nếu không bị giới hạn về thời gian và chi phí Do đó, mục tiêu chính là phát triển phần mềm chất lượng cao với chi phí hợp lý và theo lịch trình đã được xác định.
Đặc trưng phát triển và vận hành phần mềm
Một trong những khó khăn lớn nhất trong phát triển phần mềm là tính chất logic của nó, khác biệt với các hệ thống vật lý Điều này tạo ra những thách thức đáng kể trong quá trình phát triển, sử dụng và bảo trì phần mềm Dưới đây là ba yếu tố chính góp phần vào sự phức tạp này: phần mềm không được chế tạo theo nghĩa cổ điển.
Phần mềm được thiết kế và phát triển tương tự như phần cứng, nhưng không có hình thức cụ thể trước khi hoàn thiện Chỉ khi sản phẩm được phát triển xong, người ta mới có thể đánh giá hiệu quả của nó Do đó, trong các giai đoạn trung gian, việc kiểm soát chất lượng của phần mềm trở nên rất khó khăn.
Giá thành của phần cứng chủ yếu bị ảnh hưởng bởi giá nguyên vật liệu, điều này dễ kiểm soát hơn so với phần mềm Chi phí phát triển phần mềm chủ yếu phụ thuộc vào nhân lực, bao gồm kiến thức, kinh nghiệm và khả năng quản lý Quá trình này diễn ra trong một môi trường đa dạng và thay đổi liên tục, khiến việc ước lượng chi phí và hiệu quả trở nên khó khăn Hơn nữa, phần mềm không hỏng theo thời gian nhưng có thể thoái hóa, dẫn đến việc cần phải cập nhật và bảo trì thường xuyên.
Phần mềm không chỉ bị ảnh hưởng bởi môi trường mà còn thoái hóa theo thời gian, đòi hỏi phải được bảo trì để đáp ứng nhu cầu thay đổi của tổ chức Mỗi lần bảo trì, phần mềm có thể phát sinh thêm khiếm khuyết, dẫn đến việc gia tăng số lỗi tiềm ẩn Cuối cùng, sự thoái hóa này có thể gây ra tỷ lệ sai hỏng cao, dẫn đến những thiệt hại không thể chấp nhận được.
Bảo trì phần mềm phức tạp hơn nhiều so với bảo trì phần cứng do tính chất phức tạp của hệ thống và việc không có sẵn các bộ phận thay thế Thay vì thay thế bộ phận hỏng, cần phải tạo ra mô-đun mới, khiến cho chỉ nhà sản xuất phần mềm mới có khả năng sửa chữa các hỏng hóc Việc ước lượng chi phí bảo trì phần mềm cũng gặp khó khăn, vì phần lớn phần mềm thường được xây dựng từ đầu thay vì lắp ráp từ các 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 thường không thể được lắp ráp theo một khuôn mẫu cố định do yêu cầu thay đổi tùy thuộc vào môi trường cụ thể mà nó được phát triển Môi trường này bao gồm phần cứng, phần mềm nền, con người và tổ chức, và thường xuyên biến đổi, điều này khiến việc định hình trước cho phần mềm trở nên khó khă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.
Nhu cầu và độ phức tạp
Mặc dù ngành công nghiệp máy tính đã phát triển đến giai đoạn thứ tư, nhưng thách thức trong phát triển phần mềm máy tính vẫn gia tăng do nhiều nguyên nhân khác nhau.
Khả năng xây dựng các chương trình mới không theo kịp nhu cầu phần mềm ngày càng tăng, đặc biệt khi Internet phát triển mạnh mẽ và số lượng người dùng gia tăng Ngành sản xuất phần mềm hiện nay trở thành một ngành công nghiệp khổng lồ, nhưng năng suất vẫn chưa cao và không đáp ứng được yêu cầu của xã hội, dẫn đến ảnh hưởng lớn đến giá thành và chất lượng phần mềm Hơn nữa, nhiều chương trình được thiết kế và lập tài liệu sơ sài, gây khó khăn trong việc bảo trì và tốn kém tài nguyên Do đó, phát triển phần mềm mới dễ bảo trì để thay thế các hệ thống cũ trở thành một nhu cầu cấp bách.
Với sự tiến bộ của phần cứng, quy mô và độ phức tạp của phần mềm ngày càng gia tăng, đặc biệt là những phần mềm hiện đại có thể đạt hàng triệu dòng lệnh như hệ điều hành Unix và Windows Sự gia tăng độ phức tạp này tạo ra thách thức lớn trong việc phát triển phần mềm quy mô lớn, khi các kinh nghiệm từ việc sản xuất phần mềm nhỏ không còn phù hợp trong môi trường làm việc nhóm và phát triển sản phẩm quy mô lớn.
Phần cứng ngày càng tinh vi và mạnh mẽ, nhưng khả năng xây dựng phần mềm vẫn chưa theo kịp để khai thác tối đa tiềm năng này Những khó khăn và thách thức hiện tại đã thúc đẩy việc áp dụng thực hành kỹ nghệ phần mềm, nhằm tạo ra các sản phẩm phần mềm chất lượng cao, quy mô lớn và tích hợp nhiều tính năng phù hợp với khả năng của phần cứng.
Kỹ nghệ phần mềm
Định nghĩa
Kỹ nghệ phần mềm, theo định nghĩa của Fritz Bauer, là việc áp dụng các nguyên lý công nghệ chính xác nhằm phát triển phần mềm một cách kinh tế, tin cậy và hiệu quả trên các hệ thống thực tế Quá trình này bao gồm một chuỗi các bước với ba yếu tố chủ chốt.
Các yếu tố này cho phép người quản lý theo dõi tiến trình phát triển phần mềm, đồng thời cung cấp cho kỹ sư phần mềm một nền tảng vững chắc để xây dựng sản phẩm chất lượng cao một cách hiệu quả trong các giới hạn nhất định.
Để xây dựng phần mềm hiệu quả, cần tuân theo các bước kỹ thuật như lập kế hoạch, ước lượng dự án, phân tích yêu cầu hệ thống, 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 trong kỹ nghệ phần mềm thường sử dụng ký pháp đồ họa hoặc ngôn ngữ đặc biệt, cùng với các tiêu chuẩn chất lượng sản phẩm phần mềm Ngoài ra, việc áp dụng các công cụ hỗ trợ cũng là yếu tố quan trọng trong quá trình phát triển phần mềm.
Hệ thống hỗ trợ phát triển phần mềm, hay còn gọi là kỹ nghệ phần mềm có máy tính hỗ trợ (CASE), cung cấp sự hỗ trợ tự động hoặc bán tự động thông qua các phương pháp khác nhau Khi các công cụ được tích hợp và thông tin do chúng tạo ra có thể sử dụng cho các công cụ khác, quy trình phát triển phần mềm trở nên hiệu quả hơn.
Các thủ tục đóng vai trò như chất keo kết nối các phương pháp và công cụ trong phát triển phần mềm, đảm bảo chúng được sử dụng một cách hợp lý và đúng hạn.
- 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 các cột mốc quan trọng để giao sản phẩm giúp người quản lý phần mềm theo dõi tiến độ và kiểm soát kết quả hiệu quả hơn.
Sau đây, chúng ta sẽ xem xét một số cách tiếp cận (còn gọi là mô hình hay khuôn cảnh) cơ bản trong tiến trình phát triển phần mềm.
Mô hình vòng đời cổ điển
Kỹ nghệ phần mềm theo mô hình vòng đời cổ điển, hay còn gọi là mô hình thác nước, yêu cầu một quy trình phát triển hệ thống một cách tuần tự và chặt chẽ Quy trình này bắt đầu từ phân tích hệ thống, sau đó tiến hành phân tích, thiết kế, mã hóa, kiểm thử và cuối cùng là bảo trì.
Kỹ nghệ và phân tích hệ thống là quá trình thu thập yêu cầu hệ thống với thiết kế và phân tích ở mức cao, nhằm xác định phạm vi, yêu cầu và tính khả thi của phần mềm Phân tích yêu cầu phần mềm đóng vai trò quan trọng trong việc đảm bảo rằng sản phẩm cuối cùng đáp ứng nhu cầu của người dùng và các tiêu chuẩn kỹ thuật.
Phân tích yêu cầu là quá trình quan trọng trong việc thu thập và đánh giá thông tin cần thiết cho phần mềm, bao gồm các chức năng cần thực hiện, hiệu năng yêu cầu và thiết kế giao diện người dùng.
Kết quả phân tích cung cấp tài liệu về yêu cầu hệ thống và phần mềm (đặc tả yêu cầu) để khách hàng xem xét và sử dụng làm hướng dẫn cho đội ngũ phát triển.
- 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ế phần mềm bao gồm nhiều bước quan trọng, tập trung vào bốn 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, và thiết kế giao diện cùng 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áy thực hiện được e Kiểm thử
Tiến trình kiểm thử phần mềm bao gồm việc phát hiện và sửa lỗi lập trình, kiểm tra chức năng để đảm bảo phần mềm hoạt động như mong muốn, và đánh giá hiệu quả thực hiện của nó Bảo trì phần mềm cũng là một phần quan trọng trong quá trình này.
Bao gồm việc sửa chữa các lỗi phát sinh trong quá trình áp dụng chương trình, cũng như điều chỉnh nó để phù hợp với những thay đổi từ môi trường bên ngoài như hệ điều hành mới, thiết bị ngoại vi mới và yêu cầu của người dùng Ngoài ra, còn có nhu cầu bổ sung chức năng và nâng cao hiệu suất của chương trình.
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
Mô hình vòng đời cổ điển đóng vai trò quan trọng trong ngành công nghiệp phần mềm, cung cấp một tiêu chuẩn để tổ chức các phương pháp phân tích, thiết kế, mã hóa, kiểm thử và bảo trì Mặc dù có nhiều mô hình hiện đại, vòng đời cổ điển vẫn được áp dụng rộng rãi, đặc biệt cho các dự án vừa và nhỏ.
Hình 1.1: Mô hình vòng đời cổ điển.
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ó
Sau khi có bản mẫu, nhà phát triển có thể sử dụng các phần mềm hiện có hoặc công cụ hỗ trợ để tạo ra chương trình hoạt động hiệu quả.
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 dùng 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
Trong quá trình phát triển phần mềm, người phát triển và khách hàng sẽ gặp nhau để xác định mục tiêu tổng thể và các yêu cầu cần thiết Tiếp theo, giai đoạn thiết kế nhanh sẽ diễn ra, tập trung vào việc biểu diễn các khía cạnh của phần mềm mà người dùng có thể thấy, bao gồm input và output, và tạo ra một bản mẫu Người dùng sẽ đánh giá và điều chỉnh các yêu cầu cho phần mềm, và quá trình này sẽ được lặp lại cho đến khi bản mẫu đáp ứng đầy đủ yêu cầu của khách hàng, đồng thời giúp người phát triển hiểu rõ hơn về nhu cầu cần thực hiện.
Một biến thể của mô hình phát triển phần mềm 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 để hình thành sản phẩm cuối cùng Tuy nhiên, mô hình làm bản mẫu gặp phải một số vấn đề nhất đị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 thường cảm thấy thất vọng với quá trình phát triển phần mềm vì họ có thể nhầm lẫn giữa bản mẫu và sản phẩm cuối cùng Điều này dẫn đến việc họ không đầu tư đủ thời gian và công sức để đánh giá bản mẫu một cách kỹ lưỡng.
Hình 1.2: Mô hình làm bản mẫu.
Mô hình xoắn ốc
Mô hình xoắn ốc do Boehm giới thiệu vào năm 1988, nhấn mạnh tầm quan trọng của việc phân tích yếu tố rủi ro trong quá trình phát triển phần mềm Quá trình này được chia thành nhiều bước lặp lại, bắt đầu bằng việc phân tích rủi ro, tiếp theo là tạo mẫu, cải tiến và phát triển mẫu, sau đó là duyệt lại, và tiếp tục như vậy Mỗi bước trong mô hình xoắn ốc bao 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ệ
Xây dựng bản mẫu Đánh giá của khách hàng
Mỗi lần lặp xoắn ốc từ tâm giúp hoàn thiện các phiên bản dự án Nếu phân tích rủi ro cho thấy yêu cầu không rõ ràng, bản mẫu có thể được áp dụng trong giai đoạn kỹ nghệ Ngoài ra, các mô hình và mô phỏng khác cũng hỗ trợ làm rõ vấn đề và làm mịn yêu cầu.
Trong quá trình phân tích rủi ro tại một vòng xoắn ốc, việc đưa ra quyết định "tiến hành tiếp hay dừng" là rất quan trọng Nếu mức độ rủi ro được đánh giá là quá lớn, có thể cần phải đình chỉ dự án để đảm bảo an toàn và hiệu quả.
Mô hình xoắn ốc gặp khó khăn trong việc thuyết phục khách hàng lớn về tính khả thi của cách tiếp cận tiến hóa, yêu cầu tri thức chuyên gia để đánh giá rủi ro chính xác nhằm đạt được thành công Để triển khai mô hình này hiệu quả, cần có năng lực quản lý cao; nếu không, dễ dẫn đến tình trạng sửa đổi cục bộ không có kế hoạch Hơn nữa, mô hình xoắn ốc còn mới mẻ và chưa phổ biến bằng các phương pháp như vòng đời hoặc làm bản mẫu, do đó cần thêm thời gian để xác định tính hiệu quả của nó một cách chắc chắn.
Hình 1.3: Mô hình xoắn ốc.
Kế hoạch ban đầu Rủi ro ban đầu
Lập kế hoạch Phân tích rủi ro
Kế hoạch dựa trên đánh giá của khách hàng
Rủi ro dựa trên kế hoạch sửa đổi
Làm tiếp Đánh giá của khách hàng Đánh giá Kỹ nghệ
Bản mẫu đầu tiênBản mẫu tiếp theo
Kỹ thuật thế hệ thứ tư
Thuật ngữ kỹ thuật thế hệ thứ tư (4GT - fourth generation technology) bao gồm một phạm vi rộng các công cụ phần mềm có các điểm chung:
1 Cho phép người phát triển xác định một số đặc trưng của phần mềm ở mức cao
2 Tự động sinh ra mã chương trình gốc theo nhu cầu của người phát triển
Phần mềm được phát triển nhanh hơn khi ở mức trừu tượng cao, và mô hình 4GT trong kỹ nghệ phần mềm giúp xác định phần mềm gần với ngôn ngữ tự nhiên hoặc sử dụng ký pháp có ý nghĩa Hiện nay, môi trường phát triển phần mềm hỗ trợ cho khuôn khổ 4GT bao gồm nhiều công cụ khác nhau.
1 ngôn ngữ phi thủ tục để truy vấn CSDL
3 bộ thao tác dữ liệu
4 bộ tương tác và xác định màn hình
6 khả năng đồ họa mức cao
7 khả năng làm trang tính
8 khả năng tạo tài liệu
Các công cụ 4GT đã tồn tại từ lâu, nhưng chủ yếu chỉ được áp dụng trong một số lĩnh vực nhất định như tính năng macro trong phần mềm bảng tính và khả năng tự sinh mã trong các công cụ thiết kế giao diện kéo-thả Đối với các ứng dụng nhỏ, có thể dễ dàng chuyển từ bước thu thập yêu cầu sang cài đặt Tuy nhiên, với các hệ thống lớn, cần có một chiến lược thiết kế rõ ràng Việc áp dụng 4GT mà không có thiết kế cho các dự án lớn có thể dẫn đến chất lượng kém và khó khăn trong bảo trì, gây ra sự không hài lòng từ người dùng Vấn đề sử dụng khuôn cảnh 4GT vẫn còn nhiều tranh cãi.
- Người ủng hộ cho là 4GT làm giảm đáng kể thời gian phát triển phần mềm và làm tăng rất nhiều hiệu suất của người xây dựng phần mềm
Một số người phản đối cho rằng các công cụ 4GT hiện tại không phải lúc nào cũng dễ sử dụng hơn các ngôn ngữ lập trình truyền thống Họ cũng chỉ ra rằng chương trình gốc do các công cụ này tạo ra thường không hiệu quả, và việc bảo trì các hệ thống phần mềm lớn phát triển từ 4GT có thể dẫn đến những thách thức mới.
Có thể tóm tắt hiện trạng của cách tiếp cận 4GT như sau:
1 Lĩnh vực ứng dụng hiện tại cho 4GT mới chỉ giới hạn vào các ứng dụng hệ thông tin nghiệp vụ, đặc biệt, việc phân tích thông tin và làm báo cáo là nhân tố chủ chốt cho các cơ sở dữ liệu lớn Tuy nhiên, cũng đã xuất hiện các công cụ CASE mới hỗ trợ cho việc dùng 4GT để tự động sinh ra khung chương trình
2 Đối với các ứng dụng vừa và nhỏ: thời gian cần cho việc tạo ra phần mềm được giảm đáng kể và khối lượng phân tích/thiết kế cũng được rút bớt
3 Đối với ứng dụng lớn: các hoạt động phân tích, thiết kế và kiểm thử chiếm phần lớn thời gian và việc loại bỏ bớt lập trình bằng cách dùng 4GT nhiều khi đem lại hiệu quả không đáng kể so với tính rườm rà, kém hiệu quả của phần mềm xây dựng bằng phương pháp này
4GT đã trở thành yếu tố thiết yếu trong phát triển phần mềm nghiệp vụ và dự kiến sẽ được áp dụng rộng rãi trong nhiều lĩnh vực khác trong tương lai.
Mô hình lập trình cực đoan
Lập trình cực đoan (XP - eXtreme Programming) do Kent Beck phát triển là một phương pháp mới trong lĩnh vực phát triển phần mềm, mang đến nhiều hướng dẫn độc đáo, thậm chí trái ngược với các phương pháp truyền thống trước đây.
Một khái niệm quan trọng trong XP là "tạo các ca thử nghiệm trước tiên", giúp đảm bảo rằng phần mềm được phát triển đáp ứng các yêu cầu chất lượng ngay từ đầu Phương pháp này khuyến khích lập trình viên viết các bài kiểm tra trước khi bắt tay vào việc lập trình, tạo ra một quy trình phát triển phần mềm hiệu quả hơn.
Trong quá trình phát triển phần mềm, thử nghiệm thường được thực hiện ở giai đoạn cuối, khi mã nguồn đã hoàn thiện Tuy nhiên, nhiều dự án không coi trọng kiểm thử và chỉ thực hiện khi có thời gian và ngân sách Phương pháp phát triển Agile, đặc biệt là XP, đã thay đổi quan niệm này bằng cách coi kiểm thử có tầm quan trọng ngang bằng hoặc thậm chí lớn hơn việc viết mã Theo XP, các ca kiểm thử cần được thiết kế trước khi viết mã và phải được thực hiện thành công mỗi khi chương trình được tạo ra.
Tạo ca thử nghiệm trước khi phát triển modun mang lại nhiều lợi ích, bao gồm việc xác định rõ ràng giao diện và chức năng của modun Để thực hiện điều này, bạn cần hiểu rõ các yêu cầu của modun, điều này giúp tăng cường hiệu quả lập trình và đảm bảo rằng sản phẩm cuối cùng đáp ứng được nhu cầu người dùng.
XP đề xuất một khái niệm cách mạng về lập trình đôi, trong đó mã nguồn của một mô-đun phải được viết bởi hai lập trình viên cùng một máy tính Lợi ích của phương pháp này là khi một người viết mã, người còn lại sẽ suy nghĩ về vấn đề tổng thể, không chỉ tập trung vào đoạn mã hiện tại, từ đó đảm bảo chất lượng cao hơn và giải pháp toàn diện hơn Hơn nữa, việc lập trình đôi giúp họ tuân thủ các chỉ dẫn của XP, đặc biệt là việc "tạo ca thử nghiệm trước", điều mà một lập trình viên đơn lẻ có thể dễ dàng bỏ qua.
Tổ hợp các mô hình
Chúng ta đã xem xét các mô hình kỹ nghệ phần mềm như những cách tiếp cận khác nhau, nhưng có thể tổ hợp các khuôn cảnh để tận dụng sức mạnh của từng khuôn cảnh cho dự án cụ thể Ví dụ, khuôn cảnh xoắn ốc kết hợp cả làm bản mẫu và các yếu tố của vòng đời cổ điển, tạo ra một cách tiếp cận tiến hóa Kỹ thuật thế hệ thứ tư có thể được sử dụng để cài đặt bản mẫu hoặc hệ thống sản xuất trong bước mã hóa của vòng đời cổ điển, và làm bản mẫu trong bước phân tích của mô hình vòng đời cổ điển.
Kết luận, chúng ta không nên phụ thuộc vào một khuôn khổ cụ thể nào Tính chất và quy mô của phần mềm cần phát triển sẽ quyết định lựa chọn khuôn khổ Mỗi phương pháp đều có những ưu điểm riêng, và việc kết hợp khéo léo các phương pháp này sẽ tạo ra một phương pháp hỗn hợp hiệu quả hơn so với việc sử dụng từng phương pháp một cách độc lập.
Tính khả thị của quá trình kỹ nghệ
Quá trình phát triển phần mềm thường khó kiểm soát do tính chất lôgic của các phần tử, vì vậy cần làm cho quy trình này trở nên “nhìn thấy được” Mỗi bước trong phát triển phải tạo ra sản phẩm hoặc tài liệu tương ứng để người quản lý dự án và khách hàng có thể xem xét Những tài liệu này rất quan trọng cho công đoạn kiểm thử và nâng cấp phần mềm Ví dụ, trong giai đoạn phân tích, chúng ta cần các tài liệu như báo cáo nghiên cứu khả thi, mô hình hệ thống, phác họa yêu cầu và đặc tả yêu cầu.
Chúng ta hãy so sánh tính khả thị của các khuôn cảnh đã biết:
- Vòng đời cổ điển có tính khả thị cao do các bước phát triển tường minh, mô hình xoắn ốc cũng có tính khả thị tốt
- Đối với mô hình làm bản mẫu, nếu tần số sửa chữa là lớn thì tính khả thị kém và việc tạo ra tài liệu là không hiệu quả
- 4GT thì mới chỉ dùng với những ứng dụng nghiệp vụ đặc thù nên khó phát biểu gì về tính khả thị của nó
Việc xây dựng tài liệu cũng có những vấn đề như:
- Tạo ra các chi phí phụ làm chậm tiến trình phát triển
Khi gặp vấn đề về thiết kế, các nhà phát triển thường ngần ngại thay đổi tài liệu đã được phê duyệt, dẫn đến việc họ chọn các giải pháp cục bộ không hiệu quả.
Mô hình phát triển phần mềm truyền thống tập trung vào việc lập tài liệu để cải thiện tính khả thị, trong khi đó, mô hình lập trình cực đoan (XP) lại không khuyến khích việc tạo ra nhiều tài liệu.
Vấn đề giảm kích cỡ của phần mềm
Phần mềm ngày nay ngày càng lớn và phức tạp, khiến cho năng lực của nhóm lập trình không còn tỷ lệ thuận với năng lực của từng cá nhân Độ phức tạp và chi phí phát triển tăng theo cấp số nhân với kích thước của chương trình Do đó, việc giảm kích thước và độ phức tạp của phần mềm trở thành ưu tiên hàng đầu trong ngành công nghiệp phần mềm Trong giai đoạn phân tích thiết kế, chiến lược “chia để trị” được áp dụng để chia phần mềm thành các module độc lập, giúp giảm độ phức tạp tổng thể và cho phép phát triển song song Trong giai đoạn mã hóa, việc giảm kích thước có thể được thực hiện thông qua nhiều phương thức khác nhau.
- Dùng lại: dùng lại các thư viện đã phát triển, các thư viện thương mại
- Tự sinh mã: sử dụng các công cụ tự động hỗ trợ kỹ nghệ phần mềm (visual modeling tools, GUI builders, CASE tools )
Kỹ thuật hướng đối tượng là một phương pháp phát triển phần mềm giúp tạo ra các mô-đun có khả năng tái sử dụng cao, nhờ vào cơ chế che giấu thông tin và tính năng kế thừa.
Việc lựa chọn ngôn ngữ lập trình phụ thuộc vào miền ứng dụng và yêu cầu hiệu năng của phần mềm, trong đó năng lực biểu diễn của ngôn ngữ cũng đóng vai trò quan trọng Bảng 1.1 cung cấp thống kê về năng lực biểu diễn của các ngôn ngữ, thể hiện qua số dòng lệnh trên mỗi đơn vị chức năng Mặc dù Visual Basic (VB) không phải là ngôn ngữ có cấu trúc cao, nhưng nó được ưa chuộng trong các ứng dụng vừa và nhỏ trên nền tảng Windows nhờ vào tính dễ học, dễ sử dụng và năng lực biểu diễn cao.
Bảng 1.1: Năng lực biểu diễn của ngôn ngữ
Phân tích và đặc tả yêu cầu
Đại cương về phân tích và đặc tả
Phân tích và xác định yêu cầu là bước đầu tiên trong quy trình phát triển phần mềm, tập trung vào việc hiểu rõ sản phẩm cần phát triển thay vì cách thức phát triển Mục tiêu cuối cùng của quá trình này là tạo ra tài liệu đặc tả yêu cầu, đóng vai trò là hợp đồng ràng buộc giữa khách hàng và nhà phát triển.
Hoạt động phân tích giữa khách hàng và người phân tích là rất quan trọng trong phát triển phần mềm, giúp đảm bảo chất lượng và độ tin cậy của sản phẩm Khách hàng nêu yêu cầu, và người phân tích sẽ hiểu, cụ thể hóa và biểu diễn lại những yêu cầu đó Nếu quá trình phân tích không diễn ra suôn sẻ, sẽ dẫn đến hiểu lầm và sai sót, khiến cho việc sửa chữa trở nên tốn kém, đặc biệt khi lỗi được phát hiện ở các giai đoạn sau như thiết kế hay mã hóa Do đó, việc thực hiện phân tích chính xác là yếu tố then chốt để đảm bảo phần mềm đáp ứng đầy đủ yêu cầu của người sử dụng.
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 quy mô lớn thường phục vụ cho nhiều người dùng, dẫn đến sự đa dạng trong các yêu cầu và mức độ ưu tiên Điều này có thể tạo ra sự mâu thuẫn giữa các yêu cầu khác 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 hệ thống, cần phân biệt rõ giữa yêu cầu và mục tiêu Yêu cầu là những tiêu chí có thể kiểm tra được, trong khi mục tiêu thường mang tính trừu tượng hơn Chẳng hạn, một mục tiêu như "giao diện thân thiện với người sử dụng" khó có thể xác định một cách khách quan, làm cho khách hàng và nhà phát triển khó đạt được sự đồng thuận về việc phần mềm có đáp ứng yêu cầu hay không Do đó, từ mục tiêu này, yêu cầu cụ thể cho nhà phát triển có thể là "giao diện đồ họa cho phép người dùng chọn lệnh qua menu."
Giai đoạn phân tích nhằm xác định rõ ràng 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 cần phải dễ hiểu cho người dùng và đồng thời chặt chẽ, làm cơ sở cho hợp đồng và giúp các nhà phát triển xây dựng phần mềm hiệu quả.
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à:
Yêu cầu là một mô tả ngắn gọn và dễ hiểu về những gì cần thiết, nhằm giúp người đọc, bao gồm cả người sử dụng và người quản lý, nắm bắt thông tin một cách rõ ràng và hiệu quả.
Đặc tả yêu cầu cần trình bày một cách chi tiết và rõ ràng về các yêu cầu và ràng buộc của hệ thống, nhằm đảm bảo người đọc, đặc biệt là các kỹ sư phần mềm và kỹ sư hệ thống, không bị hiểu nhầm Nội dung cần chính xác để hỗ trợ quá trình phát triển và bảo trì hệ thống hiệu quả.
Việc thẩm định các tài liệu yêu cầu là cần thiết để đảm bảo đáp ứng nhu cầu người dùng và duy trì chất lượng phần mềm Trong nhiều trường hợp, việc xác định đầy đủ yêu cầu trước khi phát triển hệ thống có thể không khả thi, do đó, việc xây dựng các bản mẫu để nắm bắt yêu cầu trở nên quan trọng.
Hình 2.1: Quá trình hình thành các yêu cầu.
Nghiên cứu khả thi
Giai đoạn này đặc biệt quan trọng vì liên quan đến việc lựa chọn giải pháp Người phân tích cần làm rõ điểm mạnh và điểm yếu của hệ thống cũ, đánh giá mức độ và tầm quan trọng của từng vấn đề Đồng thời, cần xác định các vấn đề cần giải quyết như dịch vụ mới, thời hạn đáp ứng và hiệu quả kinh tế Cuối cùng, người phân tích phải đưa ra một số giải pháp khả thi để tiến hành.
Mô hình hệ thống Tài liệu định nghĩa yêu cầu
Tài liệu đặc tả yêu cầu
Xác định yêu cầu Đặc tả yêu cầu
Tài liệu yêu cầu cần so sánh các ưu điểm và nhược điểm của giải pháp, bao gồm tính năng hệ thống, chi phí cài đặt, bảo trì và đào tạo người sử dụng Việc tìm kiếm sự cân bằng giữa nhu cầu và khả năng đáp ứng là rất quan trọng Mặc dù mọi dự án đều khả thi với nguồn lực và thời gian vô hạn, nhưng thực tế thường gặp phải giới hạn về tài nguyên và khó khăn trong việc đảm bảo tiến độ bàn giao Phân tích khả thi và rủi ro có mối liên hệ chặt chẽ; nếu rủi ro của dự án cao, khả năng sản xuất phần mềm chất lượng sẽ bị ảnh hưởng tiêu cực.
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
Luận chứng kinh tế là tài liệu nghiên cứu khả thi về kinh tế, đóng vai trò nền tảng cho hầu hết các hệ thống, ngoại trừ một số lĩnh vực như quốc phòng, luật pháp và các nghiên cứu đặc biệt.
- 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 là một lĩnh vực khó khăn trong giai đoạn phân tích dự án Quá trình phân tích và xác định nhu cầu cần được thực hiện đồng thời với việc kiểm tra tính khả thi kỹ thuật Các đánh giá liên quan đến tính khả thi kỹ thuật thường rất quan trọng trong việc đảm bảo thành công của dự án.
Rủi ro trong xây dựng hệ thống liên quan đến khả năng thiết kế các phần tử sao cho chúng đạt được chức năng và hiệu suất mong muốn, đồng thời đáp ứng các ràng buộc trong quá trình phân tích.
Để xây dựng phần tử hệ thống, cần xem xét xem có sẵn nhân viên và các tài nguyên cần thiết khác như phần cứng và phần mềm hay không Việc đảm bảo rằng các nguồn lực này có sẵn là yếu tố quan trọng để tiến hành xây dựng hệ thống hiệu quả.
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?
3 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 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.
Khi đánh giá các phương án, cần xem xét khả năng vận hành trôi chảy của hệ thống trong khuôn khổ tổ chức và điều kiện quản lý hiện có 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, ảnh hưởng đến mức độ các phương án được xem xét.
Nền tảng của phân tích yêu cầu
2.3.1 Các nguyên lý phân tích
Trong hai thập kỷ qua, nhiều phương pháp phân tích và đặc tả phần mềm đã được phát triển Các nhà nghiên cứu đã chỉ ra những vấn đề và nguyên nhân của chúng, đồng thời xây dựng các quy tắc và thủ tục để khắc phục Mỗi phương pháp mang một ký pháp và quan điểm riêng, nhưng tất cả đều liên quan đến một tập hợp các nguyên lý cơ bản.
1 Miền thông tin của vấn đề phải được biểu diễn lại và hiểu rõ
2 Các mô hình mô tả cho thông tin, chức năng và hành vi hệ thống cần phải được xây dựng
3 Các mô hình (và vấn đề) phải được phân hoạch theo cách để lộ ra các chi tiết theo kiểu phân tầng (hay cấp bậc)
4 Tiến trình phân tích phải đi từ thông tin bản chất hướng tới chi tiết cài đặt. Bằng cách áp dụng những nguyên lý này, người phân tích tiếp cận tới vấn đề một cách hệ thống
Thông tin cần được trình bày rõ ràng để người đọc hiểu đầy đủ chức năng của nó Các mô hình trao đổi thông tin giúp đơn giản hóa quá trình giao tiếp Phân hoạch vấn đề là phương pháp hiệu quả để giảm thiểu độ phức tạp Cả hai góc nhìn, từ bản chất và cài đặt phần mềm, đều quan trọng để đáp ứng các ràng buộc logic và vật lý mà hệ thống yêu cầu.
Chúng ta tạo ra các mô hình để hiểu rõ hơn về thực thể cần xây dựng Đối với các vật thể vật lý như toà nhà hay máy móc, mô hình có thể giống hệt về hình dạng nhưng nhỏ hơn về quy mô Tuy nhiên, khi xây dựng phần mềm, mô hình cần có khả năng mô phỏng thông tin mà phần mềm xử lý, các chức năng thực hiện phép biến đổi, và hành vi của hệ thống khi các phép biến đổi này diễn ra.
Trong quá trình phân tích yêu cầu phần mềm, chúng ta xây dựng các mô hình hệ thống tập trung vào chức năng mà hệ thống cần thực hiện, không quan tâm đến cách thức thực hiện Các mô hình này thường sử dụng ký pháp đồ họa để mô tả thông tin, xử lý, hành vi và các đặc trưng khác của hệ thống thông qua các biểu tượng dễ nhận diện Bên cạnh đó, một số phần của mô hình có thể được trình bày bằng văn bản, với thông tin mô tả được cung cấp qua ngôn ngữ tự nhiên hoặc ngôn ngữ chuyên dụng cho yêu cầu Những mô hình này không chỉ giúp hình dung hệ thống mà còn đóng vai trò quan trọng trong việc phân tích yêu cầu.
Mô hình hỗ trợ người phân tích trong việc nắm bắt thông tin, chức năng và hành vi của hệ thống, từ đó giúp cho quá trình phân tích yêu cầu trở nên dễ dàng và có hệ thống hơn.
Mô hình đóng vai trò quan trọng trong việc xem xét và xác định tính đầy đủ, nhất quán và chính xác của đặc tả.
Mô hình đóng vai trò quan trọng trong việc thiết kế, cung cấp cho các nhà thiết kế một phương pháp biểu diễn chính về phần mềm, có khả năng được “ánh xạ” vào bối cảnh cài đặt cụ thể.
Dưới đây là một số mô hình (phương pháp) hay được dùng trong phân tích:
1 Biểu đồ luồng dữ liệu
Khi thông tin di chuyển qua phần mềm, nó trải qua nhiều phép biến đổi Biểu đồ luồng dữ liệu (Data Flow Diagram - DFD) là công cụ giúp hình dung luồng dữ liệu trong hệ thống và các phép biến đổi áp dụng lên dữ liệu Ký pháp cơ bản của DFD được thể hiện trong hình 2.2.
Biểu đồ luồng dữ liệu (DFD) là công cụ hữu ích để biểu diễn hệ thống hoặc phần mềm ở nhiều mức độ trừu tượng khác nhau DFD có thể được phân chia thành nhiều mức khác nhau để thể hiện chi tiết chức năng và luồng thông tin Phương pháp này được gọi là phân tích có cấu trúc DFD mức 0, hay còn gọi là biểu đồ nền tảng, thể hiện toàn bộ hệ thống như một hình tròn, với dữ liệu vào và ra được chỉ ra bằng các mũi tên DFD mức 1 là phiên bản chi tiết hơn của DFD mức 0, bao gồm nhiều hình tròn (chức năng) và các mũi tên (luồng dữ liệu) liên kết Mỗi tiến trình ở mức 1 là chức năng con của toàn bộ hệ thống được mô tả trong biểu đồ ngữ cảnh Hình 2.3 minh họa một DFD cho hệ thống bán vé tàu.
Hình 2.3: Biểu đồ luồng dữ liệu của một hệ thống bán vé tầu.
2 Biểu đồ thực thể quan hệ
Biểu đồ thực thể - quan hệ (ERD) là ký pháp nền tảng cho mô hình hóa dữ liệu, xác định các thành phần chính như thực thể, thuộc tính, và quan hệ Mục đích của biểu đồ ERD là để biểu diễn dữ liệu cùng với mối quan hệ giữa các thực thể.
Biểu đồ EưR có cấu trúc đơn giản, trong đó các thực thể được thể hiện bằng hình chữ nhật có nhãn, trong khi các mối quan hệ được biểu diễn bằng hình thoi Các kết nối giữa các thực thể dữ liệu và mối quan hệ được thiết lập thông qua các đường nối đặc biệt.
Khách hàng Hệ thống bán vé Đặt vé
Phân tích đơn đặt vé
Kiểm tra giờ tàu Bảng giờ tàu Đặt chỗ Phát hành vé
Chỗ đẵ đặt Bảng giá vé
Hình 2.4: Mô hình thực thể quan hệ người - phương tiện giao thông.
Người phân tích đóng vai trò đặc biệt quan trọng trong tiến trình phân tích Ngoài kinh nghiệm, một người phân tích tốt cần có các khả năng sau:
Khả năng hiểu các khái niệm trừu tượng cho phép tổ chức lại thông tin thành các phân tích logic, từ đó tổng hợp các giải pháp hiệu quả dựa trên từng phân khúc cụ thể.
- Khả năng rút ra các sự kiện thích đáng từ các nguồn xung khắc và lẫn lộn
- Khả năng hiểu được môi trường người dùng/khách hàng
- Khả năng áp dụng các phần tử hệ thống phần cứng và/hoặc phần mềm vào môi trường người sử dụng/khách hàng
- Khả năng giao tiếp tốt ở dạng viết và nói
- Khả năng trừu tượng hóa/tổng hợp vấn đề từ các sự kiện riêng lẻ.
Xác định và đặc tả yêu cầu
Xác định yêu cầu là quá trình mô tả các dịch vụ mà hệ thống cần cung cấp và các ràng buộc cần tuân thủ trong quá trình vận hành Nó chỉ tập trung vào hành vi bên ngoài của hệ thống mà không đi sâu vào chi tiết thiết kế Các yêu cầu nên được diễn đạt một cách dễ hiểu, không đòi hỏi kiến thức chuyên môn đặc biệt.
Các yêu cầu được chia thành hai loại:
1) Các yêu cầu chức năng: các dịch vụ mà hệ thống cần cung cấp
2) Các yêu cầu phi chức năng: các ràng buộc mà hệ thống cần tuân thủ
Các yêu cầu phi chức năng được phân loại thành ba nhóm chính: Thứ nhất, yêu cầu sản phẩm, bao gồm các tiêu chí về tốc độ, bộ nhớ, độ tin cậy, khả năng chuyển giao và tái sử dụng Thứ hai, yêu cầu về quá trình, liên quan đến các tiêu chuẩn và phương pháp thiết kế cũng như ngôn ngữ lập trình cần tuân thủ trong quá trình phát triển sản phẩm Cuối cùng, yêu cầu khác bao gồm các yếu tố không thuộc hai nhóm trên, như yêu cầu về tính pháp lý, chi phí và thành viên trong nhóm phát triển.
Các yêu cầu phi chức năng thường mang tính đặc thù cho từng khách hàng, điều này làm cho việc phân tích và mô tả chúng một cách đầy đủ và chính xác trở nên khó khăn.
Nguyên tắc cơ bản trong việc yêu cầu hệ thống là đảm bảo tính đầy đủ và không mâu thuẫn Tuy nhiên, đối với các hệ thống lớn và phức tạp, việc đạt được hai yếu tố này trong giai đoạn phân tích ban đầu là một thách thức Do đó, trong quá trình xem xét yêu cầu, cần thiết phải bổ sung và chỉnh sửa tài liệu yêu cầu để đảm bảo tính chính xác và nhất quán.
Tài liệu xác định yêu cầu là mô tả từ góc nhìn của khách hàng, sử dụng ngôn ngữ tự nhiên và các khái niệm trừu tượng Ngược lại, tài liệu đặc tả yêu cầu (đặc tả chức năng) hướng đến người phát triển và là cơ sở cho hợp đồng phần mềm, cần phải rõ ràng để tránh hiểu nhầm Yêu cầu mơ hồ có thể dẫn đến việc phát triển phần mềm không đúng ý khách hàng, gây ra chi phí sửa đổi cao và kéo dài thời gian bàn giao Theo thống kê, 85% mã cần viết lại do thay đổi yêu cầu và 12% lỗi trong 3 năm đầu sử dụng xuất phát từ đặc tả không chính xác Vì vậy, việc đặc tả yêu cầu một cách chính xác là vô cùng quan trọng và cần được ưu tiên.
1 Đặc tả phi hình thức: là cách đặc tả bằng ngôn ngữ tự nhiên
2 Đặc tả hình thức: là cách đặc tả bằng các ngôn ngữ nhân tạo (ngôn ngữ đặc tả), các công thức và biểu đồ Đặc tả phi hình thức (ngôn ngữ tự nhiên) thuận tiện cho việc xác định yêu cầu nhưng nhiều khi không thích hợp với đặc tả yêu cầu vì: i) Không phải lúc nào người đọc và người viết đặc tả bằng ngôn ngữ tự nhiên cũng hiều các từ như nhau ii) Ngôn ngữ tự nhiên quá mềm dẻo do đó các yêu cầu liên quan đến nhau có thể được biểu diễn bằng các hình thức hoàn toàn khác nhau và người phát triển không nhận ra các mối liên quan này iii) Các yêu cầu khó được phân hoạch một cách hữu hiệu do đó hiệu quả của việc đổi thay chỉ có thể xác định được bằng cách kiểm tra tất cả các yêu cầu chứ không phải một nhóm các yêu cầu liên quan
Các ngôn ngữ đặc tả hình thức giúp khắc phục nhiều hạn chế, nhưng phần lớn khách hàng không quen thuộc với chúng Hơn nữa, mỗi ngôn ngữ này thường chỉ phù hợp với một lĩnh vực cụ thể, và việc sử dụng chúng đòi hỏi nhiều thời gian và công sức.
Một cách tiếp cận là bên cạnh các đặc tả hình thức người ta viết các chú giải bằng ngôn ngữ tự nhiên để giúp khách hành dễ hiểu
Khi các yêu cầu được thiết lập, việc thẩm định cần được thực hiện để đảm bảo chúng đáp ứng nhu cầu của khách hàng Nếu quá trình thẩm định không được thực hiện kỹ lưỡng, sai sót có thể lan truyền sang các giai đoạn thiết kế và mã hóa, dẫn đến chi phí sửa đổi hệ thống tăng cao Mục tiêu chính của thẩm định là kiểm tra xem các yêu cầu do người phân tích xác định có thỏa mãn bốn yếu tố quan trọng hay không.
1 Thỏa mãn nhu cầu của người dùng: cần phải thỏa mãn được các nhu cầu bản chất của người dùng (khách hàng)
2 Các yêu cầu không được mâu thuẫn nhau: với các hệ thống lớn các yêu cầu rất đa dạng và có khả năng sẽ mâu thuân nhau Khi đó người phân tích phải loại bớt các yêu cầu (không chủ chốt) để sau cho các yêu cầu được mô tả trong tài liệu yêu cầu không mâu thuẫn nhau
3 Các yêu cầu phải đầy đủ: cần chứa mọi chức năng và ràng buộc mà người dùng đã nhắm đến
4 Các yêu cầu phải hiện thực: yêu cầu phải hiện thực về các khía cạnh kỹ thuật,kinh tế và pháp lý.
Làm bản mẫu trong quá trình phân tích
Trong các hệ thống phức tạp, việc hiểu rõ yêu cầu của khách hàng và đánh giá tính khả thi của hệ thống thường gặp khó khăn Một giải pháp hiệu quả là xây dựng bản mẫu, vừa giúp phân tích yêu cầu vừa có thể tiến hóa thành sản phẩm cuối cùng Bản mẫu phần mềm khác biệt so với bản mẫu phần cứng; trong khi bản mẫu phần cứng nhằm thẩm định thiết kế hệ thống, bản mẫu phần mềm chủ yếu để xác nhận yêu cầu của người sử dụng, dù thiết kế của nó có thể khác xa so với sản phẩm cuối cùng.
2.5.1 Các bước làm bản mẫu
Xây dựng bản mẫu bao gồm 6 bước sau:
Để bắt đầu quá trình phát triển phần mềm, bước đầu tiên là đánh giá yêu cầu phần mềm và xác định xem phần mềm đó có xứng đáng để làm bản mẫu hay không Không phải tất cả phần mềm đều phù hợp để trở thành bản mẫu; một số yếu tố cần xem xét bao gồm lĩnh vực ứng dụng, độ phức tạp của ứng dụng, đặc điểm của khách hàng và đặc điểm của dự án Để đảm bảo sự tương tác hiệu quả giữa khách hàng và bản mẫu, cần phải đáp ứng các điều kiện nhất định.
1 Khách hàng phải cam kết dùng tài nguyên để đánh giá và làm mịn bản mẫu (chi tiết hóa yêu cầu)
2 Khách hàng phải có khả năng đưa ra những quyết định về yêu cầu một cách kịp thời
Bước 2: Sau khi dự án được chấp thuận, người phân tích cần xây dựng một bản tóm tắt cho yêu cầu Trước khi tạo mẫu, họ phải xác định miền thông tin, các lĩnh vực, hành vi và chức năng của vấn đề, từ đó phát triển một phương pháp hợp lý để phân hoạch Việc áp dụng các nguyên lý phân tích nền tảng, như phân tích từ trên xuống (top-down) và các phương pháp phân tích yêu cầu, là rất quan trọng trong giai đoạn này.
Bước 3: Sau khi xem xét mô hình yêu cầu, cần tạo một đặc tả thiết kế ngắn gọn cho bản mẫu Thiết kế phải được thực hiện trước khi bắt đầu làm bản mẫu, tập trung chủ yếu vào các vấn đề thiết kế dữ liệu và kiến trúc mức đỉnh, không đi sâu vào thiết kế thủ tục chi tiết.
Bước 4: Tạo, kiểm thử và làm mịn phần mềm bản mẫu một cách nhanh chóng và tiết kiệm chi phí Bản mẫu lý tưởng nên được lắp ráp từ các khối chức năng có sẵn, như thư viện, và có thể sử dụng các ngôn ngữ lập trình bậc cao hoặc công cụ tự động để xây dựng.
Bước 5: Khách hàng đánh giá và hoàn thiện yêu cầu, là giai đoạn quan trọng trong quy trình phát triển phần mềm Tại đây, khách hàng có cơ hội xem xét cách thức thể hiện yêu cầu phần mềm và đưa ra những gợi ý điều chỉnh, nhằm tối ưu hóa phần mềm cho các nhu cầu thực tế của mình.
Bước 6: Tiếp tục thực hiện các bước 4 và 5 cho đến khi tất cả yêu cầu được hoàn thiện hoặc mẫu đã phát triển thành phần mềm hoàn chỉnh Phát triển bản mẫu mang lại nhiều lợi ích, bao gồm việc cải thiện khả năng đáp ứng nhu cầu người dùng và tăng cường chất lượng sản phẩm cuối cùng, nhưng cũng có những hạn chế cần lưu ý.
1 Sự hiểu lầm giữa những người phát triển phần mềm và những người sử dụng phần mềm có thể được nhận thấy rõ khi các chức năng của hệ thống được trình diễn
2 Sự thiếu hụt các dịch vụ người dùng có thể được phát hiện
3 Sự khó sử dụng hoặc sự nhầm lẫn các dịch vụ người dùng có thể được thấy rõ và được sửa lại
4 Đội ngũ phát triển phần mềm có thể tìm ra đựơc các yêu cầu không đầy đủ hoặc không kiên định khi họ phát triển bản mẫu
5 Một hệ thống hoạt động được (mặc dầu là hạn chế) là bằng chứng thuyết minh cho tính khả thi và tính hữu ích của ứng dụng cho các nhà quản lý
6 Bản mẫu đó được dùng làm cơ sở cho việc viết đặc tả một sản phẩm
Mục tiêu chính của việc tạo bản mẫu là phát triển và thẩm định các yêu cầu phần mềm, nhưng nó cũng mang lại nhiều lợi ích khác.
1 Dùng để huấn luyện người sử dụng ngay từ trước khi hệ thống được phân phối
2 Dùng trong quá trình thử nghiệm hệ thống Điều đó nghĩa là cùng các trường hợp thử như nhau vừa dùng cho thử bản mẫu vừa cho thử hệ thống Kết quả khác nhau có nghĩa là có sai sót
Tạo bản mẫu là một kỹ thuật hiệu quả để giảm thiểu rủi ro trong phát triển phần mềm, đặc biệt là khi phát hiện sai sót vào giai đoạn cuối rất tốn kém Kinh nghiệm cho thấy rằng việc sử dụng bản mẫu giúp giảm thiểu các vấn đề liên quan đến đặc tả yêu cầu, đồng thời có thể làm giảm tổng chi phí phát triển Tuy nhiên, phương pháp này cũng có những hạn chế cần được xem xét.
1 Để đơn giản hóa việc tạo bản mẫu người ta có thể bỏ qua các yêu cầu phức tạp Sự thật hẳn là không thể tạo bản mẫu một vài phần quan trọng nhất của hệ thống như các đặc điểm về sự an toàn - nguy kịch
2 Các yêu cầu phi chức năng như độ tin cậy, độ an toàn hay hiệu năng thường không được biểu thị đầy đủ trong bản mẫu
3 Do tính chưa hoàn thiện về chức năng/hiệu năng, người dùng có thể không dùng bản mẫu y như cách dùng một hệ thống thực đang hoạt động Do đó,chất lượng đánh giá của khách hàng nhiều khi không cao.