Chương V: Quy trình làm phần mềm

Chia sẻ: Trịnh Thị Thoa | Ngày: | Loại File: DOC | Số trang:68

Thêm vào BST

Báo xấu

333
lượt xem 87
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Quy trình làm phần mềm (hay gọi đơn giản theo tiếng Anh: software process - quy trình phần mềm) là quá trình tạo ra phần mềm. Quy trình này là sự kết hợp mô hình vòng đời phần mềm, các công cụ được sử dụng và quan trọng hơn hết, là những người xây dựng nên phần mềm đó.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Chương V: Quy trình làm phần mềm

CHƯƠNG V – QUI TRÌNH LÀM PHẦN MỀM. 1. MỞ ĐẦU Quy trình làm phần mềm (hay gọi đơn giản theo tiếng Anh: software process - quy trình phần mềm) là quá trình tạo ra phần mềm. Quy trình này là sự kết hợp mô hình vòng đời phần mềm, các công cụ được sử dụng và quan trọng hơn hết, là những người xây dựng nên phần mềm đó. Các công ty phần mềm khác nhau có các quy trình ph ần mềm khác nhau. Ví dụ hãy xem vấn đề tài liệu. Có một số công ty cho rằng chính bản thân phần mềm với các mã nguồn là tài liệu về phần mềm. Họ cho rằng phần mềm có thể hiểu được bằng cách đọc các mã nguồn này. Một số công ty khác chuẩn bị tài liệu rất chi tiết. Ngay cả khi phần mềm đã cài đặt cho khách hàng và chuyển sang giai đoạn bảo trì, thì mọi sự sửa đổi phần mềm cũng được ghi chép lại, các bản thiết kế cũng được thay đổi cho phù hợp. Từ thực tế có thể thấy rằng một phần mềm được kiểm thử kỹ lưỡng và có các tài liệu báo cáo đầy đủ trong từng pha thì chất lượng sẽ tốt hơn và công việc bảo trì cũng thuận lợi hơn. Nói chung, một quy trình phần mềm thường trải qua 7 pha: xác định yêu cầu, phân tích, thiết kế, cài đặt, tích hợp, bảo trì và thôi sử dụng. Trong một số trường hợp thì tên các pha này có thể khác. Ví dụ người ta hợp nhất hai pha xác định yêu cầu và phân tích thành pha phân tích h ệ thống. Một vài pha khác lại được chia nhỏ hơn, ví dụ pha thiết kế được chia thành pha thiết kế kiến trúc và thiết kế chi tiết. Hai pha cài đặt và tích hợp được kết hợp thành pha cài đặt và tích hợp. Những lý do sau đây trả lời câu hỏi vì sao các pha của vòng đời phần mềm cần được kiểm thử kỹ và báo cáo thành tài liệu chi tiết bởi nhóm thực hiện trước khi tiến hành các pha tiếp theo: - Vì sự thúc ép về thời gian hoàn thành nên những phần tài liệu bị trì hoãn thường ít khi được tiếp tục hoàn thiện. - Trách nhiệm về một pha nào đó có thể được chuyển giao cho nhóm khác thậm chí ở một công ty phần mềm khác. - Phần mềm thường liên tục thay đổi trong quá trình xây dựng. Ví dụ thiết kế có thể bị thay đổi trong pha cài đặt. Rõ ràng nếu tài liệu thiết kế được biên soạn đầy đủ thì sự sửa đổi sẽ thuận lợi hơn. 99
II. CÁC ĐỐI TƯỢNG 1. Khách hàng Khách hàng là cá nhân hoặc công ty có nhu cầu sử dụng phần mềm. 2. Người phát triển Nh ững người phát triển là những người nhận trách nhiệm xây dựng phần mềm do khách hàng yêu cầu. 3. Người sử dụng Người sử dụng là người trực tiếp sử dụng phần mềm khi nó được cài đặt cho khách hàng. Khách hàng, người phát triển và người sử dụng có thể ở các công ty khác nhau hoặc ở ngay trong một công ty. Cũng có khi họ là những người lao động tự do. Thường thì khách hàng và người sử dụng ở cùng một công ty, còn những người phát triển là thành viên của một công ty phần mềm nào đó. Nếu xét về mặt giá cả thì người ta phân các phần mềm thành hai loại: Phần mềm được xây dựng cho một khách hàng thường có giá cao, và phần mềm đóng gói được bán cho nhiều khách hàng ví dụ như Microsoft Word, Microsoft Excel...thường có giá rẻ hơn. Trong những lần gặp đầu tiên giữa khách hàng và người phát triển, khách hàng phác thảo các yêu cầu, chức năng, các công việc cần thực hiện của phần mềm mà họ muốn đặt hàng. Theo cách nhìn nh ận của người phát triển thì những điều khách hàng mô tả có thể mơ hồ, có những điều không hợp lý, thậm chí mâu thuẫn hay không khả thi. Nhiệm vụ của người phát triển là phải tìm hiểu xem thực chất khách hàng cần gì. Ngoài những yêu cầu về chức năng và công việc, họ còn phải tìm hiểu xem các điều kiện về phần mềm là gì? Ví dụ như phần mềm phải hoàn thành trong thời gian bao lâu, phần mềm cần làm việc với hệ điều hành nào, trên máy tính có cấu hình ra sao, giá cả khoảng bao nhiêu thì chấp nhận được. Thường thì chính khách hàng hỏi lại người phát triển giá của phần mềm, và người phát triển phải cân nhắc khi trả lời câu hỏi này. III – PHA XÁC ĐỊNH YÊU CẦU 1. Nắm bắt yêu cầu 100
Quá trình khám phá các yêu c ầu của khách hàng được gọi là sự nắm bắt yêu cầu (requirements capture), hoặc sự gợi mở yêu cầu (requirements elicitation) hay tìm hiểu vấn đề (concept exploration). Sau khi các yêu cầu được xác định thì chúng được xem xét để hiệu chỉnh, lược bỏ bớt hoặc mở rộng. Quá trình này được gọi là phân tích yêu cầu (requrements analysis). Pha yêu cầu thường được bắt đầu bằng việc gặp gỡ trao đổi giữa một vài thành viên của nhóm yêu cầu và một vài thành viên đại diện cho công ty khách hàng để cùng nhau xác định xem sản phẩm phần mềm cần những gì. Cuộc trao đổi thường được thực hiện theo cách là thành viên của nhóm yêu cầu đưa ra các câu hỏi có tính gợi mở về lĩnh vực mà phần mềm được sử dụng. Các thành viên của công ty khách hàng hoặc trả lời các câu hỏi của nhóm yêu cầu, hoặc chủ động nêu ra các vấn đề mà họ cần. Rõ ràng, những thành viên tham gia khám phá yêu cầu của khách hàng phải có hiểu viết về lĩnh vực mà phần mềm ứng dụng giải quyết, để có thể hiểu được những điều khách hàng nói, và có thể đưa ra các câu hỏi có ý nghĩa. Vì vậy, nhiệm vụ đầu tiên của nhóm yêu cầu chính là tìm hiểu và làm quen với lĩnh vực ứng dụng của phần mềm mà khách hàng muốn có. Ví dụ, nếu phần mềm là quản lý các chuyến bay của một hãng hàng không thì l ĩnh vực cần tìm hiểu là cách thức quản lý các chuyến bay của một hãng hàng không. Nếu phần mềm là chương trình quản lý thư viện thì nhóm yêu cầu cần có hiểu biết nhất định về lĩnh vực thư viện...Để sử dụng từ một cách chính xác, các thành viên nhóm yêu c ầu cần tìm hiểu các thuật ngữ. Ví dụ, nếu họ đang chuẩn bị làm phần mềm trong lĩnh vực sinh học thì cần tìm hiểu các thuật ngữ về sinh học. Một trong những phương pháp khắc phục vấn đề thuật ngữ là xây dựng bộ từ vựng về lĩnh vực ứng dụng. Mỗi lần gặp một thuật ngữ mới thì nhóm yêu cầu cần tìm hiểu để biết được một cách chính xác ý nghĩa và đưa thuật ngữ này vào bộ từ vựng. Sau khi đã có những hiểu biết nhất định về lĩnh vực ứng dụng phần mềm, các thành viên bắt đầu khám phá, tìm hiểu các yêu cầu khách hàng theo các cách thức sau: 1.1. Phỏng vấn khách hàng Có hai ki ểu phỏng vấn: có cấu trúc (structured) và không có cấu trúc (unstructured). Với kiểu phỏng vấn cấu trúc thì các câu hỏi đóng (close- ended) và được chuẩn bị trước. Ví dụ như: "công ty sử dụng bao nhiêu nhân 101
viên bán hàng", "lương trung bình của các nhân viên trong công ty là bao nhiêu"... Trong cách phỏng vấn không có cấu trúc thì các câu hỏi có tính mở (open-ended) được đưa ra. Ví dụ: "Hãy nêu ra một vài điểm yếu của phần mềm đang sử dụng mà khách hàng có ý định thay thế". Tuy nhiên, cũng không nên hỏi những câu quá chung chung, khó trả lời như: "Hãy nói cho tôi biết về sản phẩm hiện tại". Các câu hỏi mở nên đưa ra sao cho có thể khích lệ người được phỏng vấn có thể cho câu trả lời trong một phạm vi rộng, tuy nhiên cũng không nên rộng quá mà chỉ nằm trong phạm vi các thông tin cần nắm bắt. Phỏng vấn có hiệu quả là công việc không dễ dàng. Điều kiện quan trọng đầu tiên là người phỏng vấn cần am hiểu về lĩnh vực mà họ chuẩn bị phỏng vấn. Các câu hỏi đưa ra cũng phải hợp lý để người được phỏng vấn có thể nói ra những thông tin có ích cần thiết một cách tự nhiên, không bị gò ép hay e ngại gì. Đôi khi những câu hỏi quá thẳng thắn và trực tiếp chưa chắc đã nhận được câu trả lời đúng. Ví dụ nếu hỏi rằng "lương anh chị rất thấp, nhưng chi tiêu thì có vẻ rất nhiều. Anh chị hãy cho biết làm sao có được khoản tiền ngoài lương kia..." thì thường là người được hỏi sẽ tìm cách né tránh câu trả lời thật. Sau khi phỏng vấn xong thì người phỏng vấn cần viết báo cáo về kết quả phỏng vấn và nên đưa cho người được phỏng vấn xem và góp ý kiến. 1.2. Kịch bản (scenario) K ịch bản là một kỹ thuật được sử dụng để phân tích yêu cầu. Kịch bản là mô tả các thao tác cần thực hiện trên phần mềm cần xây dựng để hoàn thành một công việc nào đó (trong các công việc mà phần mềm cung cấp). 1.3. Một vài kỹ thuật nắm bắt yêu cầu khác M ột kỹ thuật khác hay được sử dụng để nắm bắt các yêu cầu khách hàng là gửi các bảng câu hỏi cho một số thành viên đại diện của công ty khách hàng. Bằng cách này có thể gửi cho hàng trăm thành viên để nhận được các câu trả lời dưới dạng viết, được suy nghĩ kỹ. Tuy nhiên, nếu từ bảng câu hỏi đã được trả lời, người phỏng vấn có thể đưa ra thêm các câu hỏi thích hợp với người được phỏng vấn thì có thể nhận được các thông tin bổ ích. Đôi khi các thông tin này có ích hơn nhiều so với trả lời viết đã có. 102
Một cách khác để tìm hiểu và nắm bắt yêu cầu khách hàng, đặc biệt trong môi trường kinh doanh, là xem xét các biểu mẫu khác nhau mà các khách hàng sử dụng. Ví dụ, từ việc xem xét các biểu mẫu được in ra có thể biết được các dạng báo cáo, cỡ giấy; tài liệu viết về cách thức điều hành hoặc mô tả công việc là những công cụ rất hữu ích để giúp tìm ra công việc gì đang được thực hiện, và được thực hiện như thế nào ở công ty khách hàng. Gần đây, người ta thường áp dụng thêm một phương pháp nữa là quay băng video cảnh làm việc ở công ty khách hàng (tất nhiên là được sự cho phép của công ty và của những người được quay). Như vậy, có thể biết được chính xác những gì đang xảy ra. Tuy nhiên, cách này có một nhược điểm là phải tốn khá nhiều thời gian để xem lại băng và phân tích để rút ra những thông tin cần thiết. Một nhược điểm rất lớn khác của phương pháp này là phần lớn những người được quay đều không thích mình xuất hiện trong máy quay và trở nên dè dặt khi hành động. Sau khi thu được các thông tin ban đầu về yêu cầu khách hàng, bước tiếp theo là phân tích các yêu cầu đó để rút ra những thông tin cơ bản nhất có thể giúp ích cho việc xây dựng phần mềm. 2. Phân tích yêu cầu Tới thời điểm này, nhóm yêu cầu đã có được tập hợp khởi đầu các yêu cầu khách hàng. Các yêu cầu này được phân làm hai loại: chức năng (functional) và phi chức năng (nonfunctional). Yêu cầu chức năng thường gắn với chức năng tương ứng của phần mềm cần xây dựng và thể hiện dưới dạng các mục chọn của thực đơn, ví dụ như: "Phần mềm cung cấp chức năng tìm kiếm hàng hóa theo tên hàng và ngày bán". Đặc tả phi chức năng dùng để chỉ rõ tính chất nào đó của phần mềm cần xây dựng, ví dụ tính tin cậy và bảo trì được; hoặc liên quan đến môi trường mà phần mềm được sử dụng, ví dụ: tất cả các mã khách hàng được nhập trực tiếp từ bàn phím và được lưu trong một tệp bảng dữ liệu". Tóm lại yêu cầu chức năng là nói đến một công việc cụ thể, thường thể hiện bằng các mục chọn trong chương trình; còn yêu cầu phi chức năng thì nói về các tính chất của phần mềm, các tính chất này không thể thể hiện được bằng một 103
việc cụ thể. Thí dụ từ câu: "yêu cầu phần mềm phải có giao diện đẹp, thân thiện với người sử dụng", ta không thể nói được cụ thể là phải làm gì. Một điều rất quan trọng là phần mềm phải theo dõi được (traceable). Điều này có nghĩa là có thể kiểm tra xem tất cả các yêu cầu đã được thể hiện trong bản đặc tả chưa; điểm nào trong bản báo cáo yêu cầu tương ứng với điểm nào trong báo cáo đặc tả. Tương tự, báo cáo thiết kế hay chương trình cũng phải tương ứng với các tài liệu trước đó. Như vậy, nhóm bảo đảm chất lượng phần mềm có thể kiểm tra xem có phải tất cả các mục trong các yêu cầu khách hàng đã được thực hiện hay chưa. Tất cả các yêu cầu thu thập được ban đầu đều được đưa cho khách hàng xem xét. Họ sẽ sắp xếp các mục yêu cầu theo thứ tự quan trọng, phát hiện và hiệu chỉnh những điều không chính xác hoặc bỏ đi những mục không cần thiết... Tiếp theo, nhóm yêu cầu sẽ thảo luận với những khách hàng đã được phỏng vấn và xem xét lại các vấn đề một cách kỹ càng, xem có điều gì còn bị bỏ sót không. Và như chúng ta biết, kỹ thuật phân tích yêu cầu hiệu quả và chính xác nhất là làm bản mẫu, vì vậy nếu có thể thì nhóm chuyển qua bước làm bản mẫu để đưa cho khách hàng xem xét một cách trực quan hơn. 3. Làm bản mẫu (prototyping) Bản mẫu được xem là kỹ thuật phân tích yêu cầu chính xác nhất. Bản mẫu là phần mềm được xây dựng nhanh chủ yếu để thể hiện các chức năng quan trọng nhất của phần mềm cần xây dựng. Mục đích của bản mẫu là thể hiện các yêu cầu khách hàng, do đó khi xây dựng người ta chú ý nhiều đến giao diện và các báo cáo in ra. Những vấn đề quan trọng khác mà một phần mềm sản phẩm cần phải có như tính bảo mật, an toàn dữ liệu, tốc độ tính toán, kiểm tra và khắc phục lỗi... đều chưa được chú ý khi làm bản mẫu; nghĩa là bản mẫu chỉ là thể hiện bên ngoài của sản phẩm và bỏ qua những phần được che dấu. Bản mẫu được cài đặt để khách hàng sử dụng thử. Qua việc thao tác trực tiếp với bản mẫu, họ sẽ thấy được các chức năng của phần mềm đã thể hiện đúng các yêu cầu của họ chưa, cái gì cần thêm bớt hay hiệu chỉnh bổ sung. Những người phát triển sẽ hiệu chỉnh bản mẫu cho đến khi khách hàng vừa ý và cho rằng mọi yêu cầu của họ đã được bao hàm 104
trong phần mềm (tất nhiên là về hình thức). Bản mẫu sẽ được dùng làm cơ sở để biên soạn tài liệu đặc tả. Như tên gọi của nó, bản mẫu nhanh (rapid prototype) được xây dựng với mục đích để người phát triển và khách hàng thống nhất càng nhanh càng tốt những điều mà sản phẩm chính cần làm. Như vậy, nhiều điều có thể bỏ qua khi làm bản mẫu. Bản mẫu có thể thường xuyên gặp sự cố và phải khởi động lại; màn hình nhập dữ liệu có thể chưa đẹp; báo cáo in ra còn thiếu biểu tượng công ty khách hàng,... 4. Tính thân thiện với người dùng của phần mềm Khách hàng thao tác v ới bản mẫu thông qua giao diện người sử dụng (user interface) hay còn gọi là "giao diện người máy" (human-computer interface, HCI). Nên khuyến khích khách hàng làm quen và chú ý t ới giao diện người máy. Điều này có thể giúp cho sản phẩm sau này đạt được "tính thân thiện với người sử dụng" (user-friendliness), một tiêu chuẩn quan trọng của tất cả các phần mềm. Một phần mềm có tính thân thiện với người sử dụng có nghĩa là phần mềm đó dễ học sử dụng đối với cả những người ít hiểu biết về máy tính. Một chương trình thân thiện với người sử dụng thường bao gồm các yếu tố sau: dùng thực đơn hoặc các biểu tượng thay cho lệnh phải nhớ; luôn có sẵn trợ giúp màn hình mỗi khi ấn phím; các chức năng của chương trình được tổ chức trên bàn phím theo một trật tự logic; các thông báo lỗi có giải thích nguyên nhân và cách khắc phục; các tính năng trung gian và phức tạp được làm ẩn, không nhìn thấy để khỏi gây rối màn hình và lẫn lộn cho người mới học... Bản mẫu nên được xây dựng có giao diện người máy thân thiện với người dùng (user-friendly HCI). HCI c ủa bản mẫu gần giống với HCI của sản phẩm thật, như vậy sau này khách hàng sẽ nhanh chóng làm quen với sản phẩm thật và cảm thấy là các yêu cầu của họ đã được đáp ứng. 5. Bản mẫu như một kỹ thuật đặc tả 105
Bản mẫu được sử dụng như một công cụ để xác định rằng: các yêu cầu của khách hàng đã được nhận biết một cách chính xác. Khi bản đặc tả hoàn thành và được ký duyệt bởi khách hàng thì vai trò của bản mẫu cũng kết thúc. Tuy nhiên, có một cách tiếp cận khác là người ta xem bản mẫu như đặc tả, hoặc một phần quan trọng của đặc tả. Như vậy, không cần tốn thời gian viết bản đặc tả và những khó khăn thường gặp trong phần đặc tả như sự không rõ ràng, thiếu các thành phần hoặc có sự mâu thuẫn sẽ không còn. Vì bản mẫu thay thế đặc tả, nên ta chỉ cần ghi chú rằng: sản phẩm thật sẽ hoạt động giống như bản mẫu, đồng thời liệt kê thêm các đặc trưng khác mà sản phẩm cần có như cập nhật tệp, bảo mật, xử lý lỗi... Tuy nhiên, việc sử dụng bản mẫu như đặc tả cũng có nhiều nhược điểm khó khắc phục. Đặc tả là tài liệu được khách hàng ký duyệt, là căn cứ để nhà phát triển và khách hàng ký hợp đồng. Rõ ràng, bản mẫu không thể thay thế vai trò này của đặc tả, không thể căn cứ vào bản mẫu để kết luận rằng điểm này hay điểm khác của hợp đồng chưa được thực hiện đúng. Cho dù phần mềm được phát triển trong nội bộ cơ quan thì vẫn có thể có vấn đề nảy sinh giữa người phát triển và người quản lý. Rõ ràng, các nhà phát triển không thể chỉ dựa vào bản mẫu để thuyết phục các nhà quản lý là họ đã làm đúng các yêu cầu mà cơ quan đặt ra. Lý do thứ hai khiến cho việc sử dụng bản mẫu làm đặc tả bị hạn chế là vấn đề bảo trì. Cho dù có đầy đủ các tài liệu thì việc bảo trì bao giờ cũng là công việc khó khăn và tốn nhiều tiền của. Nếu thiếu tài liệu đặc tả thì việc bảo trì thực sự trở thành cơn ác mộng. Đặc biệt với công việc bảo trì nâng cao (enhancement), tức là thay đổi các yêu cầu ban đầu thì công việc thay đổi lại thiết kế đặc biệt khó khăn nếu không có tài liệu đặc tả. Vậy chỉ nên xem bản mẫu là một kỹ thuật phân tích yêu cầu. Nó được sử dụng để bảo đảm rằng các yêu cầu của khách hàng đã được nắm bắt một cách đầy đủ và chính xác. Bước tiếp theo là dựa vào bản mẫu để biên soạn tài liệu đặc tả dưới dạng văn bản. Có nên sử dụng lại bản mẫu? Thực tế cho thấy rằng cho dù về hình thức bản mẫu giống với sản phẩm thật và có thể hiệu chỉnh để trở thành sản phẩm thật, nhưng về chất lượng thực sự thì bản mẫu và sản phẩm thật còn một khoảng cách rất lớn. Ví dụ như phần lưu trữ dữ liệu hay một số phần chất lượng cao như thuật toán tối 106
ưu, tính bảo mật,...còn chưa có trong bản mẫu. Kinh nghiệm cho thấy rằng nên thiết kế lại và xây dựng lại hoàn toàn phần mềm. Chỉ nên sử dụng một số phần của bản mẫu được tạo nên bởi các bộ công cụ CASE như bộ tạo màn hình (screen generator), tạo báo cáo (report generator). Cũng có khi bản mẫu và bản chính không sử dụng cùng một ngôn ngữ lập trình. Trong trường hợp này thì việc viết lại hoàn toàn bản chính là điều khá hiển nhiên, không thể khác được. 6. Sử dụng các công cụ CASE trong pha yêu cầu Có thể sử dụng một ngôn ngữ lập trình nào đó để viết bản mẫu. Vai trò của bản mẫu là cầu nối giữa người phát triển và khách hàng để người phát triển nắm bắt nhanh và đầy đủ các yêu cầu khách hàng. Như vậy bản mẫu cần được viết càng nhanh càng tốt. Người ta thấy rằng ngôn ngữ lập trình thông dịch (interpreted language) khá thích hợp cho việc xây dựng bản mẫu, vì không mất thời gian để dịch hay liên kết như ngôn ngữ biên dịch (compiler). Tính hiệu quả được nâng cao nếu công cụ CASE được liên kết cùng với ngôn ngữ lập trình. Các ngôn ngữ có hỗ trợ công cụ CASE như Smalltalk, Java, Perl (Practical Extraction and Report Language) có thể sử dụng để xây dựng bản mẫu nhanh và hiệu quả. HTML cũng là một ngôn ngữ làm bản mẫu được ưa chuộng. Nếu bản mẫu chắc chắn được vứt đi thì HTML còn một lợi điểm nữa: thật khó hình dung sản phẩm chuyển giao lại được viết bằng HTML, như vậy việc viết bản mẫu bằng HTML gần như được ngầm hiểu là bản mẫu sẽ được vứt đi. Trong những năm gần đây, một số ngôn ngữ lập trình thuộc thế hệ thứ 4 (fourth-generation laguage, 4GL) như Oracle, PowerBuilder và DB2 cũng được sử dụng để làm bản mẫu. Mục đích thiết kế của hầu hết 4GL là viết ít dòng lệnh hơn cho cùng một chức năng so với ngôn ngữ thế hệ thứ 3 như Java, Ada hay C++. Phần lớn 4GL là thông dịch và được hỗ trợ các công cụ CASE tính năng cao, do đó làm tăng tốc độ xây dựng bản mẫu. Tuy nhiên 4GL cũng có nhược điểm. Môi trường CASE trong đó 4GL được nhúng thường là một phần của một tập hợp lớn hơn các công cụ được sử dụng cho một quy trình phần mềm đầy đủ (complete software process). Các nhà cung cấp 4GL thường khuyến khích sử dụng ngôn ngữ của họ làm bản 107
mẫu, sau đó hoàn thiện dần thành bản chính thức. Các nhà cung cấp không nhận thức được rằng bằng cách này quy trình phần mềm có thể suy thoái thành mô hình xây dựng-và-hiệu chỉnh (build-and-fixed model). Đáng tiếc là các nhà cung cấp 4GL muốn khách hàng mua sản phẩm của họ và họ quảng cáo rằng công cụ CASE của họ có thể thực hiện mọi phần công việc của một dự án phần mềm. Giả sử rằng người quản lý dự án đã bỏ ra khá nhiều tiền để mua công cụ CASE hỗ trợ cho tất cả các pha của quy trình phần mềm. Thật khó thuyết phục họ bỏ thêm tiền mua một ngôn ngữ khác để phát triển phần mềm chính thức và bỏ đi bản mẫu vừa mới xây dựng. Tuy nhiên, cần chỉ cho họ thấy rằng cho dù như vậy vẫn còn rẻ hơn là cố giữ lại bản mẫu và phát triển nó thành sản phẩm chính thức. Sẽ tốn một số tiền khổng lồ cho việc chuyển đổi bản mẫu thành bản chính thức và bảo trì sau này. 7. Kiểm thử pha xác định yêu cầu Trong m ỗi công ty phần mềm cần có một nhóm làm việc mà nhiệm vụ chính của họ là bảo đảm rằng phần mềm hoạt động tốt và đáp ứng đúng các yêu cầu của khách hàng. Nhóm này được gọi là nhóm bảo đảm chất lượng phần mềm (SQA = software quality assurance). Nhóm SQA bắt đầu thực hiện vai trò của mình ngay từ pha khởi đầu. Nếu sử dụng bản mẫu thì trong pha này nhóm cùng khách hàng kiểm thử phiên bản cuối cùng của bản mẫu xem nó đã thực hiện đúng các yêu cầu mà khách hàng cần hay không. 8. Tài liệu báo cáo trong pha xác định yêu cầu Tài liệu được biên soạn trong pha yêu cầu bao gồm bản mẫu và các ghi chép trong quá trình trao đổi với khách hàng. Những ghi chép này chính là cơ sở để những người phát triển xây dựng và sửa đổi bản mẫu. Nếu nhóm phát triển không làm bản mẫu thì tài liệu sẽ mô tả những yêu cầu của khách hàng. Tài liệu này được kiểm tra bởi khách hàng và một số người sử dụng trước khi được nhóm SQA kiểm tra kỹ lưỡng và chi tiết. IV – PHA ĐẶC TẢ CÓ CẤU TRÚC Pha đặc tả hay còn được gọi là pha phân tích, là tiếp theo pha yêu cầu. Nếu gọi là pha phân tích thì dễ nhầm với giai đoạn phân tích yêu cầu trong pha yêu 108
cầu, do đó người ta thường gọi là pha đặc tả (specification). Tài liệu báo cáo của pha này phải thỏa mãn hai yêu cầu trái ngược nhau. Một mặt, tài liệu phải rõ ràng, dễ hiểu đối với khách hàng, thường là những người không phải là chuyên gia máy tính. Mặt khác, tài liệu đặc tả lại phải đầy đủ và chi tiết, bởi vì đây gần như là nguồn duy nhất để soạn thảo thiết kế. Như vậy tài liệu đặc tả là mô tả sản phẩm trong một khuôn dạng không mang tính kỹ thuật quá, sao cho có thể dễ hiểu đối với khách hàng, nhưng đồng thời cũng phải đủ chính xác để căn cứ vào đó có thể xây dựng được phần mềm không có lỗi, đúng như yêu cầu của khách hàng. Chúng ta sẽ tìm hiểu hai kỹ thuật đặc tả: kỹ thuật cổ điển hay còn gọi là kỹ thuật đặc tả có cấu trúc (hoặc còn gọi là phân tích có cấu trúc) và phân tích hướng đối tượng. Chương này, chúng ta sẽ tìm hiểu kỹ thuật đặc tả có cấu trúc, còn trong chương 5 tiếp theo sẽ nghiên cứu kỹ thuật đặc tả hướng đối tượng hay còn được gọi đơn giản là phân tích hướng đối tượng. Lưu ý rằng trong thuật ngữ "phân tích có cấu trúc" thì từ "cấu trúc" đóng vai trò tính từ bổ nghĩa cho phân tích. Thuật ngữ này được dịch từ tiếng Anh là "structured analysis" hoặc "structured specification". Như vậy, nếu dịch đúng thì phải là "phân tích theo ki ểu cấu trúc". Từ "cấu trúc" ở đây khác với ý nghĩa của từ "cấu trúc" trong câu "phân tích cấu trúc câu", vì trong câu này thì từ "cấu trúc" là danh từ. Thuật ngữ "phân tích hướng đối tượng" cũng được dịch từ thuật ngữ tiếng Anh là "object-oriented analysis", và cũng có nghĩa là "phân tích theo kiểu hướng đối tượng". Như vậy, cùng một hệ thống cần xây dựng, nhưng ta có thể nhìn nhận và xem xét theo phương pháp cấu trúc hoặc theo phương pháp hướng đối tượng. Để bạn đọc tránh được sự hiểu nhầm, chúng tôi đôi khi sẽ gọi là "phân tích (hay đặc tả) theo phương pháp cấu trúc" và "phân tích theo phương pháp hướng đối tượng". Tuy nhiên, thường thì chúng tôi cũng viết đơn giản là "phân tích có cấu trúc" và "phân tích hướng đối tượng" như các tài liệu khác thường sử dụng. Chúng ta sẽ sử dụng khá nhiều lần thuật ngữ "hệ thống". Từ "hệ thống" ở đây là nói tới phần mềm cần xây dựng được đặt trong môi trường nó được ứng dụng. Cho nên ta nói "phân tích hệ thống", có nghĩa là ta xem xét chương trình cần xây dựng cùng với các yếu tố liên quan. Ví dụ, với chương trình quản lý bán hàng thì ta xem xét chương trình cùng với các thao tác liên quan 109
đến người bán hàng và khách hàng... Tóm lại, khi nói "phân tích hệ thống" thì ta hiểu đó chính là phân tích phần mềm cần xây dựng. 1. Tài liệu đặc tả Ta đã biết rằng tài liệu trong pha yêu cầu hoặc là bản mẫu, tức là chương trình trong đó chỉ chú ý đến giao diện, cốt thể hiện được các yêu cầu của khách hàng; hoặc là tài liệu mô tả các yêu cầu của khách hàng được viết bằng ngôn ngữ tự nhiên. Nhiệm vụ của pha đặc tả là mô tả phần mềm thực hiện các yêu cầu đó. Phải mô tả đầy đủ và chi tiết, sao cho có thể dựa vào đó để đánh giá phần mềm sau này có đáp ứng được yêu cầu đặt ra hay không. Tài liệu đặc tả còn là cơ sở để thực hiện thiết kế. Nếu như tài liệu đặc tả trả lời câu hỏi "phần mềm phải làm những việc gì?" thì tài liệu thiết kế lại trả lời câu hỏi "phải làm những việc đó như thế nào?". Vào những năm 60, 70 của thế kỷ trước, người ta vẫn dùng ngôn ngữ tự nhiên để viết tài liệu đặc tả. Tuy nhiên, người ta phát hiện rằng tài liệu biên soạn theo kiểu như thế này rất hay lỗi và có nhiều điều mập mờ. Ví dụ, chỉ với tài liệu đặc tả của Naur (1969) cho vấn đề xử lý văn bản mà từ đó có thể viết thành chương trình khoảng từ 25 đến 30 dòng lệnh, người ta đã phát hiện ra nhiều lỗi. Trong năm 1985, Mayer đã viết một bài báo nói về vấn đề này. Mayer đưa ra kết luận rằng: nếu dùng ngôn ngữ tự nhiên để viết đặc tả thì sẽ dẫn đến tình trạng tài liệu đặc tả chứa đựng các mâu thuẫn, những điều nhập nhằng không hiểu được nghĩa chính xác hoặc bị thiếu, không đầy đủ. Ông đề nghị sử dụng các thuật ngữ toán học để biểu diễn đặc tả một cách hình thức. Mayer đã dùng cách này để đặc tả vấn đề xử lý văn bản và từ đặc tả toán học ông đã chuyển đổi thành đặc tả bằng tiếng Anh. Tuy nhiên người ta lại tìm thấy những điều nhập nhằng trong đặc tả tiếng Anh này. Vậy ngôn ngữ tự nhiên không phải là cách thức tốt để biểu diễn đặc tả. Vào những năm 70, có một số tác giả đã dùng các biểu tượng trực quan (đồ họa) để biểu diễn đặc tả. Có ba kỹ thuật đồ họa đã trở thành nổi tiếng và được sử dụng nhiều. Đó là của DeMarco (1978), Gane và Sarsen (1979), Yourdon và Constantine (1979). Cả ba kỹ thuật này đều khá tốt và về cơ bản là tương đương. Tuy nhiên kỹ thuật 110
của Gane và Sarsen được sử dụng nhiều hơn và do đó chúng ta sẽ tìm hiểu kỹ thuật này trong các phần tiếp theo. 2. Phân tích hệ thống bằng phương pháp cấu trúc Ph ương pháp phân tích có cấu trúc (structured analysis, SA) do DeMacro và những người khác đề xuất vào khoảng những năm 70 của thế kỷ trước. Phương pháp này ngày nay vẫn còn phát huy tác dụng, đặc biệt là với các hệ thống thông tin quản lý. Nó vẫn là nền tảng của một số phần mềm trợ giúp phân tích và thiết kế nổi tiếng, như Designer 2000 của Oracle chẳng hạn. Đặc điểm của phương pháp này là đơn giản, dễ thực hiện nhưng không quá sơ lược. Công cụ chính được sử dụng là biểu đồ luồng dữ liệu (data flow diagram, DFD) mà ta sẽ tìm hiểu trong các phần sau. Mục đích của SA là tiến hành phân tích các chức năng của hệ thống thực tế để thành lập một mô hình logic cho hệ thống, dưới dạng một hay nhiều DFD. Nó vận dụng ba kỹ thuật: - Kỹ thuật phân mức, hay còn gọi là phân tích từ trên xuống (top-down analysis): thực chất là phân rã yếu tố phức tạp thành các yếu tố đơn giản hơn. - Kỹ thuật chuyển đổi DFD vật lý (trong đó chứa đựng các yếu tố vật lý như đĩa, băng từ, giấy, máy in...) thành DFD logic (đã loại bỏ các yếu tố vật lý). - Kỹ thuật chuyển đổi DFD của hệ thống cũ thành DFD của hệ thống mới bằng cách thêm, bớt, hiệu chỉnh lại các yếu tố trên DFD cũ. 2.1. Một số kỹ thuật thường sử dụng trong công nghệ phần mềm Các k ỹ sư phần mềm thường sử dụng hai loại công cụ: loại công cụ dùng để phân tích (analytical tool) như tinh chỉnh từng bước (stepwise refinement) hoặc phân tích mối quan hệ vốn-lãi (cost-benefit analysis), và các phần mềm được dùng để phát triển, bảo trì các phần mềm khác. Các bộ phần mềm đóng vai trò như máy cái để phát triển các phần mềm khác được gọi là công cụ CASE (computer-aided software engineering). Trong ph ần này, chúng ta sẽ chỉ xem xét kỹ thuật tinh chỉnh từng bước, là kỹ thuật được làm nền tảng cho rất nhiều kỹ thuật khác của công nghệ phần mềm. Bản chất của 111
tinh chỉnh là "hoãn đưa ra các quyết định về chi tiết đến chừng nào có thể, nhằm tập trung vào các điểm trọng yếu nhất". Lý do sử dụng kỹ thuật tinh chỉnh chính là định luật do Miller đưa ra vào năm 1956, trong đó nói rằng con người ta cùng lúc chỉ có thể tập trung sự chú ý của họ vào một vấn đề. Khi phát triển phần mềm thường có khá nhiều vấn đề cần xem xét trong cùng thời gian. Ví dụ như class thường có nhiều hơn 7 thuộc tính và phương thức, mỗi khách hàng thường có nhiều hơn 7 yêu cầu... Kỹ thuật tinh chỉnh giúp cho các kỹ sư phần mềm chỉ cần chú ý tới khoảng 7 vấn đề thích hợp nhất tại mỗi thời điểm trong quá trình phát triển phần mềm. 2.2. Một số dạng biểu đồ thường sử dụng Nh ư chúng tôi đã đề cập, việc dùng đồ họa để biểu diễn các vấn đề được sử dụng từ khá lâu và tỏ ra khá hiệu quả, không chỉ riêng trong lĩnh vực công nghệ phần mềm mà cả trong các lĩnh vực khác. Biểu diễn đồ họa cho chúng ta một hình ảnh trực quan, dễ nắm bắt hơn là viết hoặc sử dụng lời nói. Trong công nghệ phần mềm, kỹ thuật này chủ yếu được dùng từ pha đặc tả, nhưng đôi khi được sử dụng cả trong pha yêu cầu để làm cho vấn đề được rõ ràng hơn. Ví dụ, trong pha yêu cầu có thể dùng sơ đồ biểu diễn tổ chức một cơ quan, sự trao đổi thông tin giữa các bộ phận... Ta thường gặp những dạng sơ đồ sau đây trong công nghệ phần mềm: 2.2.1. Biểu đồ phân cấp chức năng (FD) Biểu đồ phân cấp chức năng (functional diagram, FD) là loại biểu đồ có cấu trúc cây diễn tả sự phân rã dần dần các chức năng từ đại thể đến chi tiết. Mỗi nút trong biểu đồ là một chức năng, và quan hệ duy nhất giữa các nút là quan hệ bao hàm: chức năng trong nút cha bao gồm các chức năng trong các nút con. Hình 5.1. sau là biểu đồ biểu diễn các chức năng quản lý của một doanh nghiệp. Quản lý doanh nghiệp Qlý nhân sự Q.lý vật tư Q.lý tài chính Q.lý khách hàng Kế toán Kế toán Trả công Theo dõi tổng hợp nhân sự thu chi 112
Hình 5.1. Một biểu đồ phân cấp chức năng Đặc điểm của biểu đồ chức năng là: - Cho một cách nhìn khái quát, từ đại thể đến chi tiết về các chức năng, nhiệm vụ cần thực hiện. - Dễ xây dựng, bằng các phân rã dần các chức năng từ trên xuống. - Thiếu sự trao đổi thông tin giữa các chức năng. Đối với hệ thống phức tạp thì sự trao đổi thông tin giữa các chức năng là không thể thiếu, do đó biểu đồ này chỉ được sử dụng làm mô hình chức năng như phần mở đầu của pha đặc tả, hoặc thậm chí được sử dụng trong pha yêu cầu hoặc trong phần riêng về tìm hiểu lĩnh vực ứng dụng. Đối với hệ thống đơn giản, các chức năng được xử lý một cách độc lập (tức là không có trao đổi thông tin cho nhau) thì mô hình phân tích chức năng có thể sử dụng làm tài liệu đặc tả cho hệ thống. Có thể thấy rằng, những xử lý thực sự chỉ xẩy ra ở các nút lá, vì ch ức năng ở nút cha lại được phân rã thành các chức năng ở các nút con của nó. Thường thì chức năng ở nút lá là khá đơn giản, có thể giải thích trực tiếp mà không cần phân rã tiếp. Cách diễn tả thao tác cần thực hiện ở nút lá được gọi là đặc tả chức năng và gọi tắt là P-spec (process specification). Mô tả này thường được trình bày một cách ngắn gọn, không vượt quá một trang giấy A4, và gồm hai phần: đầu đề và thân. Đầu đề gồm tên chức năng, các dữ liệu vào, dữ liệu hoặc kết quả ra. Phần thân mô tả nội dung xử lý, ví dụ công thức toán học, bảng hoặc cây quyết định, sơ đồ khối, ngôn ngữ tự nhiên cấu trúc hóa. Hình sau là một ví dụ về đặc tả chức năng. Đầu đề: Tên chức năng:Trả công Đầu vào: Hệ số lương a và số ngày công n trong tháng Đầu ra: Lương Thân: Lương = n*a*10 113
Hình 5.2. Một P-spec Chú ý: Cần phân biệt FD với sơ đồ tổ chức một cơ quan. Ví dụ như sơ đồ sau: Ban Giám đốc Phòng tổ chức Phòng tài vụ Phòng vật tư Phòng kinh doanh Hình 5.3. Một sơ đồ tổ chức Bởi sự phân cấp quản lý cũng thường được áp dụng trong các cơ quan, cho nên sơ đồ tổ chức cũng có dạng cây. Nói chung cũng có sự tương ứng giữa tổ chức và chức năng, nhưng sự tương ứng này không nhất thiết là 1-1, do đó cấu trúc cây phân cấp chức năng có thể không có dạng như cây sơ đồ tổ chức. Các nút trên cây chức năng biểu thị các chức năng tức là công việc cần thực hiện; còn các nút trên cây sơ đồ tổ chức lại là tên các bộ phận... Sơ đồ tổ chức chỉ được dùng khi cần thiết trong pha yêu cầu hoặc trong phần riêng về tìm hiểu lĩnh vực ứng dụng. 2.2.2. Các lưu đồ hệ thống (SD) L ưu đồ hệ thống (systematic diagram) là một loại biểu đồ được sử dụng để diễn tả quá trình xử lý thông tin của một hệ thống với các đặc điểm sau: - Sự diễn tả là ở mức vật lý, nghĩa là chỉ rõ cả phương tiện xử lý, ví dụ đưa thông tin ra trên giấy hay băng từ, đĩa từ... - Chỉ rõ các công việc cần thực hiện. - Chỉ rõ trình tự các công việc và các thông tin được chuyển giao giữa các công việc đó. Loại biểu đồ này được IBM đề xuất. SD phục vụ cho sự diễn tả ở mức độ vật lý và cũng khá dễ hiểu. SD được sử dụng nhiều vào những năm 60-70 của thế kỷ trước. Chúng thường được sử dụng ở giai đoạn khảo sát hệ thống cũ hoặc ở giai đoạn thiết kế. Ngày nay các phương tiện xử lý và lưu trữ thông tin khá đa dạng, nên việc xây dựng biểu đồ quá chi tiết, chỉ rõ cả các phương 114
tiện lưu trữ sẽ làm cho biểu đồ trở nên quá phức tạp và bị hạn chế trong ứng dụng, do đó người ta ít sử dụng. 2.2.3. Biểu đồ luồng dữ liệu (DFD) Bi ểu đồ luồng dữ liệu, tên tiếng Anh là "data flow diagram" (DFD), là một loại biểu đồ được sử dụng để diễn tả quá trình xử lý thông tin của một hệ thống với các đặc điểm sau: - Sự diễn tả là ở mức logic (nghĩa là không chỉ rõ phương tiện xử lý và lưu trữ thông tin). - Chỉ rõ các công việc cần thực hiện. - Chỉ rõ trình tự các công việc và các thông tin được chuyển giao giữa các công việc đó. Các tác giả sử dụng một số biểu tượng khác nhau để biểu diễn DFD. Sau đây là 4 biểu tượng mà Gane và Sarsen đã sử dụng: (1) Các tác nhân: Một tác nhân (hay còn được gọi chính xác hơn là tác nhân ngoài hay điểm mút), là một thực thể ngoài hệ thống, có trao đổi thông tin với hệ thống. (Thực thể là một đối tượng tồn tại trong thế giới thực, ví dụ: người, dự án, xe máy) Tác nhân trong DFD được biểu diễn bằng một hình vuông, bên trong là tên tác nhân. Ví dụ tác nhân "khách hàng" được biểu diễn như sau: Khách hàng (Một số tác giả sử dụng biểu tượng hình chữ nhật) (2) Các chức năng: Một chức năng là một thao tác biến đổi dữ liệu (thao tác này có thể gồm nhiều thao tác khác nên còn được gọi là quá trình). Chức năng được biểu diễn bằng hình chữ nhật có góc tròn. Ví dụ chức năng "lập hóa đơn" được biểu diễn như sau: Lập hóa đơn (Một số tác giả sử dụng hình tròn hoặc hình ô van. (3) Các luồng dữ liệu: một luồng dữ liệu là một tuyến truyền dẫn thông tin. 115
Luồng dữ liệu được biểu diễn bằng mũi tên, phía trên mũi tên là tên của luồng dữ liệu. Ví dụ luồng dữ liệu "hóa đơn đã lập" được biểu diễn như sau: Hóa đơn đã lập (4) Các kho dữ liệu: Một kho dữ liệu là nơi chứa dữ liệu để sử dụng về sau. Tên kho dữ liệu được chứa trong một hình chữ nhật mở về phía bên phải. Ví dụ kho dữ liệu "Hàng hóa" chứa danh sách các mặt hàng được biểu diễn như sau: Hàng hóa Có tác giả sử dụngbiểu tượng là hai đoạn thẳng song song, ở giữa là tên kho dữ liệu. Ví dụ kho dữ liệu "khách hàng" chứa danh sách các khách hàng được biểu diễn như sau: Hàng hóa Ghi chú: từ định nghĩa các biểu tượng, ta có thể rút ra một số điều cần lưu ý như sau: - Không có luồng dữ liệu giữa hai tác nhân ngoài. Ví d ụ với hệ thống phần mềm hỗ trợ bán hàng của cửa hàng H có thể có các tác nhân ngoài là khách hàng K và nhà cung c ấp C. Rõ ràng có thể có mối liên hệ giữa khách hàng K với nhà cung cấp C, nhưng mối liên hệ này không liên quan đến hệ thống nên không được đưa vào biểu đồ. - Không có luồng dữ liệu trực tiếp giữa hai kho dữ liệu (vì không có hai kho khác nhau chứa cùng một loại dữ liệu) - Nếu luồng dữ liệu cùng tên với đầu ra của chức năng thì không cần viết lên luồng dữ liệu. Ví dụ: Khách Lập hóa hàng đơn 116
Khi sử dụng DFD để làm tài liệu đặc tả người ta thường bổ sung thêm một số yếu tố nữa. Ví dụ, ta thêm vào biểu đồ những biểu tượng diễn tả sự điều khiển. Cũng giống với biểu đồ phân cấp chức năng, trong DFD đối với các chức năng đơn giản ở mức cuối cùng phải có thêm P-spec, tức là bản đặc tả chức năng. 2.2.4. Một số dạng biểu đồ khác Ngoài các d ạng biểu đồ nói trên người ta còn sử dụng nhiều dạng biểu đồ khác, như biểu đồ MERISE chẳng hạn. Thậm chí, đôi khi nếu thấy cần thiết, người ta có thể tự tạo lấy biểu đồ để diễn tả vấn đề của mình (ví dụ biểu đồ diễn tả quá trình trao đổi công văn giấy tờ ở một cơ quan chẳng hạn). Nói cho cùng, mục tiêu của chúng ta là xây dựng được phần mềm đúng như mong đợi, vừa dễ bảo trì lại hoạt động chính xác. Nếu bằng cách nào đó, có thể làm được điều này và có thể giải thích cho mọi người hiểu thì ta có thể làm. Những kiến thức về công nghệ phần mềm mà con người đã tích lũy được dĩ nhiên là nguồn tham khảo quý giá. 2.2.5. Các phương tiện đặc tả chức năng M ột điểm chung trong FD và DFD là để diễn tả một yếu tố, ta phân rã nó thành các yếu tố đơn giản hơn. Ví dụ như với FD chẳng hạn, ta phân rã các chức năng theo sơ đồ hình cây cho đến khi gặp chức năng đơn giản nhất không phân rã được nữa thì dừng lại. Trên cây biểu diễn thì chức năng không phân rã được thể hiện bằng nút lá và phải giải thích cụ thể. Cách giải thích này được gọi là đặc tả chức năng (P-Spec), như chúng ta đã xem xét ở phần trên. Ở ví dụ trên, ta đã dùng một công thức toán học làm phương tiện mô tả trong phần thân của P-spec (Lương= n*a*10). Người ta còn sử dụng một số phương tiện khác như sau: - Các bảng quyết định và cây quyết định. Được sử dụng khi chức năng được đặc tả thực chất là một sự phân chia các trường hợp tùy thuộc vào một điều kiện nào đó. - Các sơ đồ khối. Sơ đồ khối sử dụng 3 loại biểu tượng: hình thoi biểu diễn điều kiện, hình chữ nhật biểu diễn hành động phải làm và mũi tên biểu diễn sự chuyển giao 117
điều khiển (chuyển giao quyền thực hiện). Với vấn đề đơn giản thì việc diễn tả bằng sơ đồ khối khá dễ hiểu, vì vậy nó thích hợp cho người mới lập trình. Nếu như các DFD chỉ tập trung diễn tả những việc phải làm thì sơ đồ khối ngoài các việc phải làm, còn chỉ ra cách dẫn dắt thực hiện các việc đó. Vì vậy với vấn đề lớn, có nhiều yếu tố và nhiều mối quan hệ thì sơ đồ khối rất phức tạp và khó xây dựng. Do đó sơ đồ khối không thích hợp cho việc diễn tả các chức năng phức tạp. - Ngôn ngữ giả lập trình (mã giả). Về hình thức trông giống ngôn ngữ lập trình nhưng bỏ đi những chi tiết cụ thể. Mục đích là giúp người đọc hiểu được thuật toán và cách thức viết chương trình cho một ngôn ngữ lập trình bất kỳ nào đó. 2.3. Phân tích có cấu trúc một hệ thống cụ thể Có thể nói rằng: không có một chuẩn mực chung để theo đó cứ thực hiện từng bước là có thể xây dựng nên một phần mềm đáp ứng được yêu cầu đặt ra. Cho dù đã có những nguyên lý chung, nhưng với từng vấn đề cụ thể, mỗi kỹ sư phần mềm lại có cách nhìn nhận và phân tích khác nhau, do đó đưa ra các cách giải quyết vấn đề khác nhau. Bây giờ chúng ta sẽ bắt đầu công việc phân tích theo phương pháp cấu trúc cho một bài toán cụ thể: xây dựng phần mềm hỗ trợ công việc bán hàng cho một cửa hàng chuyên bán các đĩa CD lưu trữ các phần mềm máy tính, như đĩa cài đặt Vietkey, Microsoft Office, VB, đĩa trò chơi... Giả sử chủ nhân của cửa hàng có tên là Hoa. Hoa mua các ph ần mềm từ các nhà cung cấp khác nhau và bán lại cho khách hàng. Cô lưu trữ các đĩa được nhiều người ưa chuộng và đặt mua các loại đĩa khác nếu cần. Hoa cho một vài cơ quan và cá nhân có thể mua chịu. Có thể hình dung công việc hàng ngày của Hoa diễn ra như sau: Khi có khách hàng đến, hoặc là họ xem catalog chứa danh sách các băng đĩa, hoặc họ nói ra tên băng đĩa cần mua. Hoa sẽ xem trên các ngăn để đĩa, hoặc trong catalog để tìm đĩa mà khách yêu cầu. Nếu tìm thấy thì Hoa sẽ xem trong danh sách khách hàng xem người khách này còn nợ không. Nếu khách đồng ý mua thì hoặc là Hoa viết hoá đơn thanh toán bằng tiền mặt, hoặc lại ghi vào sổ nợ. Giả sử bạn là người giúp Hoa tin học hóa công việc bán hàng này, và Hoa trở thành khách hàng đặt bạn làm phần mềm. Gane và Sarsen đã 118