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

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 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 100 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 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à 101 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ó. 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à 102 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 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 103 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 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, 104 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ả 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 105 đ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 ư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 106 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 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 107 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 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 108 [...]... 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ụ... 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 đế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ủ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ử... 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... 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... 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... ra từ năm 1976 bởi P.P.Chen Tuy nhiên, hiện nay ERM như đang được hồi sinh vì nó trở thành một phần tử của OOA 4 Kiểm thử pha đặc tả Như đã nói dến trong chương 1, phần lớn các lỗi trong phần mềm chuyển giao cho khách hàng thường do lỗi trong tài liệu đặc tả gây nên Các lỗi này chỉ bị phát hiện khi phần mềm được cài đặt trên máy tính của khách hàng Vì vậy nhóm SQA cần phải kiểm tra tài liệu đặc tả... của đặc tả, ví dụ các phần cứng nói đến trong phần này thực sự có phù hợp với việc cài đặt phần mềm không, dung lượng các bộ nhớ trên máy khách hàng có đủ để vận hành phần mềm không Tài liệu đặc tả phải có thể kiểm thử được, ví dụ có thể dựa vào tài liệu này mà kiểm tra tiến độ công việc thực hiện, có thể so sánh với từng mục trong pha yêu cầu Tài liệu đặc tả cũng nên có các phần, các mục được đánh... 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... 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 đã đề nghị một kỹ thuật gồm 9 bước để phân tích nhu cầu khách hàng (ở đây là khách hàng đặt làm phần mềm, vậy chính là Hoa) như sau: Kho luồng Bước 1 Xây dựng DFD (biểu đồđĩa CD dữ liệu) Căn cứ vào vấn đề thực tế, bước đầu tiênvềcó thể xây . 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. 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ụ. 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