Các kỹ thuật thực hành để thu thập và quản lý yêu cầu trên toàn bộ chu trình phát triển sản phẩm phần mềm Microsoft Press, 1st Edition

Nội dung text: Các kỹ thuật thực hành để thu thập và quản lý yêu cầu trên toàn bộ chu trình phát triển sản phẩm phần mềm Microsoft Press, 1st Edition

1. TỦ SÁCH CÔNG NGHỆTHÔNG TIN SATA-APTECH tuyển chọn & giới thiệu Tác giả: Karl E. Wiegers Software Requirements Best Practices Các kỹ thuật thực hành để thu thập và quản lý yêu cầu trên toàn bộ chu trình phát triển sản phẩm phần mềm Microsoft Press, 1st Edition Người dịch: Hoàng Xuân Thịnh Phiên bản bản dịch: 10.12.30 Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 1
2. GIỚI THIỆU “TỦ SÁCH CÔNG NGHỆ THÔNG TIN” Đểphát triển, ngành công nghiệp công nghệthông tin Việt Nam phải hướng ra thịtrường thếgiới, do đó phải tuân theo các chuẩn mực toàn cầu nhưlàm việc theo quy trình, áp dụng các tiêu chuẩn quản lý chất lượng sản phẩm và dịch vụphổbiến (ISO 27000, CMMI ), áp dụng các hướng dẫn thực hành tốt và tốt nhất. Vì vậy, đối với các sinh viên đang theo học ngành công nghệthông tin và chuẩn bịra làm việc, chúng tôi nghĩrằng, các cuốn sách hướng dẫn kỹthuật, hướng dẫn xây dựng quy trình làm việc, hướng dẫn cách tổchức công việc nhằm nâng cao năng suất lao động có vai trò hết sức quan trọng. Những cuốn sách này giúp người đọc nhận thức vềcác chuẩn mực công nghiệp trong ngành công nghệthông tin thếgiới, học hỏi vềcách những đồng nghiệp trên toàn cầu của họlàm việc nhưthếnào, qua đó người đọc có thểsẽthay đổi suy nghĩcủa mình sao cho gần hơn với các chuẩn mực và cách làm việc đó. Sự thay đổi trong nhận thức theo chiều hướng này càng diễn ra sâu rộng bao nhiêu thì càng thúc đẩy công nghiệp công nghệthông tin Việt Nam phát triển bấy nhiêu. Đểđáp ứng nhu cầu sách tham khảo theo chiều hướng đó, chúng tôi xây dựng “Tủsách công nghệthông tin” bằng cách tuyển chọn và giới thiệu các bản dịch tiếng Việt của các cuốn sách có nội dung đáp ứng các tiêu chí sau: 1. Có thểlàm tài liệu tham khảo cho sinh viên các khoa công nghệthông tin đểhọbiết thêm vềthực tiễn ngành công nghiệp công nghệthông tin thếgiới. 2. Hướng dẫn xây dựng quy trình làm việc, quản lý chất lượng sản phẩm và dịch vụmột cách thực tiễn, không hàn lâm, có thểứng dụng được ngay vào thực tếcông việc hàng ngày của mỗi người làm việc trong ngành công nghệthông tin. 3. Giới thiệu các “hướng dẫn thực hành tốt” (good practices) và “hướng dẫn thực hành tốt nhất” (best practices) trong công nghiệp công nghệthông tin. 4. Giới thiệu các xu hướng công nghệmới trong ngành công nghệthông tin thếgiới. Nói gọn lại, thông qua “Tủsách công nghệthông tin”, chúng tôi muốn góp phần cổvũxây dựng một nền “VĂN HÓA CÔNG NGHIỆP” trong ngành công nghệthông tin của Đất nước chúng ta, điều hết sức cần thiết đểViệt Nam có một ngành công nghiệp công nghệthông tin phát triển và hiện đại, đóng góp cho sựgiầu mạnh của Đất nước. Cuốn sách đầu tiên trong “Tủsách công nghệthông tin” là cuốn “Software Requirement Best Practices” (Các hướng dẫn thực hành tốt nhất vềyêu cầu phần mềm) do Microsoft Press xuất bản. Đây là cuốn sách hết sức cần thiết cho những ai đang thực hiện các dựán công nghệ thông tin và các sinh viên ngành công nghệthông tin muốn có thêm hiểu biết vềthực tiễn ngành trước khi ra làm việc. Xin trân trọng giới thiệu cùng bạn đọc. SATA-APTECH Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 2
3. LỜI GIỚI THIỆU CỦA NGƯỜI DỊCH Trong những năm qua tôi đã tham gia một số dự án CNTT và tôi thấy rất thiếu những tài liệu có giá trị bằng tiếng Việt để tham khảo về cách thức tiến hành các dự án này. Tài liệu nước ngoài thì rất nhiều và khá nhiều tài liệu hay, nhưng tài liệu hướng dẫn chi tiết thành một quy trình làm việc thì cũng không nhiều. Cách đây mấy năm, trong một chuyến công tác, tôi mua được cuốn sách Software Requirements của tác giả Karl E. Wiegers do Microsoft Press ấn hành. Cuốn này hiện đã có ấn bản mới cũng của Microsoft Press. Trong cuốn sách này tác giả trình bày toàn bộ một quy trình biến nhu cầu sử dụng phần mềm của khách hàng thành một bản đặc tả yêu cầu phần mềm.Bản đặc tả yêu cầu phần mềm này sẽ trở thành đầu vào cho quy trình phát triển, triển khai và bảo trì một sản phẩm phần mềm. Trong Quy trình lập kế hoạch chất lượng trên satablog2, nhà tưvấn chất lượng Juran đã dành Bước 2 - Định danh khách hàng và Bước 3 – Khám phá nhu cầu khách hàng để mô tả cách thức hiện thức hóa nhu cầu của khách hàng thành một bản đặc tả sản phẩm – Juran nhấn mạnh đấy là điều kiện cần để sản xuất được sản phẩm có chất lượng. Toàn bộ Bước 2 và Bước 3 trong quy trình trên được Karl E. Wiegers cụ thể hóa thành một cuốn sách hay, dễ đọc và thiết thực áp dụng cho việc sản xuất phần mềm. Ở đây, tôi muốn nói tới sự phân biệt giữa thuật ngữ “nhu cầu” (need) của Juran và thuật ngữ “yêu cầu” của Wiegers. Để phân biệt giữa nhu cầu và yêu cầu tôi lấy ví dụ này. Cả người Việt Nam lẫn người Mỹ đều có nhu cầu nhưnhau là ăn nhanh, ăn ngon, ăn sạch vào bữa sáng. Nhưng do sự khác nhau về văn hóa mà cái nhu cầu ấy thể hiện ra bên ngoài thành các yêu cầu khác nhau, đối với người Mỹ thông thường là một bữa sáng với bánh mỳ nhanh của McDonald và một hộp Coca-Cola, đối với người Việt miền Bắc thông thường là một bát phở và một chén nước chè. Nhu cầu là cái bên trong được thể hiện ra bên ngoài thành những yêu cầu khác nhau nhưvậy. Juran đã viết khá kỹ về sự khác biệt này trong Quy trình lập kế hoạch chất lượng. Chúc các bạn thu thập được các hướng dẫn thực hành thiết thực khi đọc cuốn sách này! Hoàng Xuân Thịnh, 12/2010 Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 3
4. Dành tặng Miss Chris Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 4
5. LỜI NÓI ĐẦU Mặc dù ngành công nghiệp phần mềm đã có trên năm mươi năm kinh nghiệm thực tế nhưng nhiều tổ chức phát triển phần mềm vẫn phải vật lộn với việc thu thập, tài liệu hoá, quản lý các yêu cầu đầu vào đối với sản phẩm của mình. Thiếu đầu vào từ người dùng, yêu cầu không đầy đủ và thay đổi yêu cầu là những lý do chính khiến các tổ chức phát triển phần mềm không giao được cho khách hàng sản phẩm phần mềm với các chức năng đã được khách hàng đưa vào kế hoạch sản xuất theo đúng lịch biểu và ngân sách đã định. Nhiều nhà phát triển phần mềm không cảm thấy hài lòng với việc thu thập yêu cầu từ khách hàng. Công nghệ yêu cầu (requirement engineering) trong thực tế không được phổ biến rộng rãi tới các nhà phát triển, trong trường học sinh viên cũng không được học các kỹ thuật của công nghệ yêu cầu. Thậm chí, ngay những người tham gia dự án phần mềm còn không thống nhất được với nhau nội dung của thuật ngữ “yêu cầu”. Phát triển phần mềm cũng liên quan đến truyền thông (communication) (ý nói là sự truyền thông hay là giao tiếp giữa nhóm phát triển phần mềm và khách hàng mua phần mềm, từđó nhóm phát triển mới hiểu khách hàng cần gì ởsản phẩm phần mềm sẽxây dựng - ND) nhiều nhưlà liên quan đến tính toán (computing), tuy nhiên thường thì chúng ta hay nhấn mạnh đến khía cạnh tính toán mà bỏ quên truyền thông. Cuốn sách này cung cấp các công cụ thúc đẩy việc truyền thông và giúp các nhà phát triển và khách hàng của họ sử dụng hiệu quả các phương pháp của công nghệ yêu cầu. Cuốn sách đưa ra nhiều cách tiếp cận nhằm giúp nhóm dự án và khách hàng của dự án thoả thuận về những gì phần mềm cần đáp ứng để thoả mãn nhu cầu người dùng, cùng với cách thức để tài liệu hoá và quản lý các thay đổi trong các thoả thuận đó. Các kỹ thuật được giới thiệu ở đây thuộc loại “thực hành tốt” (good practices) của công nghệ yêu cầu, chúng không phải là các kỹ thuật “xa lạ” từ giới hàn lâm hoặc là một phương pháp luận khái quát để giải quyết bài toán yêu cầu của bạn. LỢI ÍCH TỪ CUỐN SÁCH NÀY Trong số các cải tiến quy trình phần mềm mà bạn có thể nắm bắt, các thực hành quản lý và phát triển yêu cầu được cải tiến sẽ cung cấp lợi ích lớn nhất cho bạn. Các khái niệm và phương pháp ở đây là độc lập với các phương pháp luận phát triển cụ thể, độc lập với các miền ứng dụng – dù bạn phát triển phần mềm viễn Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 5
6. thông hay tài chính bạn vẫn dùng những phương pháp này, bạn có thể sử dụng chúng trong một miền rộng lớn các loại dự án. Tôi tập trung mô tả một số kỹ thuật thực hành đã được chứng minh tính hiệu quả nhằm giúp bạn: Đạt được sự hài lòng cao hơn của khách hàng. Giảm chi phí bảo trì và hỗ trợ. Cải thiện chất lượng các yêu cầu trong dự án ngay từ sớm trong chu trình phát triển, giảm bớt các công việc phải làm lại và cải thiện năng suất. Đáp ứng các mục tiêu của lịch biểu bằng cách kiểm soát sự phá vỡ phạm vi ứng dụng của phần mềm và các thay đổi yêu cầu. Mục đích của tôi là giúp bạn cải thiện quy trình bạn sử dụng để thu thập, phân tích yêu cầu, viết và kiểm tra đặc tả yêu cầu (requirement specification), quản lý yêu cầu trên toàn bộ chu trình phát triển sản phẩm. Cải tiến quy trình nhằm giúp nhóm dự án làm việc theo cách mới để tạo ra các kết quả tốt hơn. Vì vậy tôi hy vọng bạn sẽ thực hành những gì viết ở đây thay vì chỉ đọc chúng. NGHIÊN CỨU TÌNH HUỐNG Nhằm giúp bạn ứng dụng các phương pháp ở đây, tôi đã cung cấp các ví dụ là một số nghiên cứu tình huống từ các dự án hiện tại, một trong số đó là hệ thống IT có kích thước trung bình được gọi là Chemical Tracking System (Đừng lo lắng - Bạn không cần phải biết bất cứ thứ gì về hóa học để hiểu dự án này). Ví dụ này được thảo luận liên tục trong các tình huống khác nhau để bạn thấy các khía cạnh khác nhau của cùng một bài toán, các đoạn đối thoại giữa các thành viên nhóm dự án đó cũng được đưa ra nhằm minh họa bài toán. AI NÊN ĐỌC CUỐN SÁCH NÀY? Bất cứ ai có công việc liên quan đến yêu cầu trong một dự án phát triển mới hay nâng cấp một sản phẩm phần mềm đều có thể tìm thấy những thông tin hữu ích ở đây. Độc giả của cuốn sách có thể gồm: analysts (người phân tích), developers (người phát triển), testers (người kiểm thử) - những người phải hiểu và đáp ứng kỳ vọng của khách hàng. Một nhóm độc giả thứ hai là những người dùng muốn hình dung một sản phẩm phần mềm đáp ứng nhu cầu về chức năng và nhu cầu sử dụng của bản thân họ. Các khách hàng muốn đảm bảo rằng sản phẩm sẽ đáp ứng các nhu cầu kinh doanh của mình sẽ hiểu tốt hơn về bản chất và tầm quan trọng của quy Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 6
7. trình yêu cầu. Các nhà quản lý dự án phải đối mặt với việc bàn giao sản phẩm đúng thời hạn sẽ học được cách thức quản lý các thay đổi yêu cầu tiềm tàng. KẾT CẤU CUỐN SÁCH Cuốn sách được tổ chức thành 3 phần. Phần I bắt đầu bằng việc giới thiệu một số định nghĩa nền tảng về công nghệ yêu cầu và mô tả một số đặc tính của các yêu cầu tuyệt hảo. Phần II giới thiệu nhiều kỹ thuật phát triển yêu cầu, bắt đầu bằng định nghĩa yêu cầu nghiệp vụ, tầm nhìn (vision) và phạm vi. Phần III giới thiệu các nguyên lý và thực hành về quản lý yêu cầu. TỪ NGUYÊN LÝ TỚI THỰC TẾ Khó khăn biết bao khi tập trung năng lượng cần thiết nhằm vượt qua những trở ngại để thay đổi và để đưa các hiểu biết mới vào hoạt động thực tế. Con người và các tổ chức có xu hướng giữ nguyên, duy trì những gì đã có, dù rằng chúng không hiệu quả. Để giúp đỡ bạn trong hành trình cải tiến quy trình yêu cầu, mỗi chương sẽ có một mục gọi là “Các bước tiếp theo” – mô tả chi tiết các hành động cụ thể để bạn áp dụng các phương pháp được giới thiệu trong chương này vào thực tế. Tôi cung cấp các templates cho các tài liệu yêu cầu, các checklists, một bảng tính xếp thứ tự ưu tiên yêu cầu, và nhiều thứ nữa trên trang web của tôi tại Hãy bắt đầu từ những thay đổi nhỏ trong công việc của bạn ngay ngày hôm nay. Không phải tất cả những người tham gia dự án của bạn đều ủng hộ bạn trong những thay đổi này. Hãy sử dụng những hiểu biết thu thập được ở đây để thuyết phục họ, hãy lôi kéo họ cùng học và cùng cải tiến. Bạn không cần phải khởi động một dự án mới để bắt đầu áp dụng những kỹ thuật của công nghệ yêu cầu. Một điểm bắt đầu tốt là hãy sử dụng một quy trình kiểm soát thay đổi thích hợp. Nghĩa là, bạn có thể mau chóng bắt đầu bằng việc quản lý các đề xuất thay đổi yêu cầu. Khi bạn thêm các tính năng mới vào sản phẩm đã có, hãy bắt đầu phân tích ảnh hưởng một cách hệ thống và tạo một ma trận lần vết để liên kết các yêu cầu mới tới các bản thiết kế, mã nguồn và tình huống kiểm thử (test cases) tương ứng. Rất hiếm khi bạn quay lại và viết lại những bản đặc tả yêu Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 7
8. cầu mới cho một hệ thống đã có. Tuy nhiên, bạn có thể viết các yêu cầu cho phiên bản tiếp theo bằng một cách chặt chẽ hơn so với trước đây, viết các analysis models cho các tính năng mới, kiểm tra các yêu cầu mới. Thực hành dần các kỹ thuật của công nghệ yêu cầu là một cách tiếp cận cải tiến quy trình có độ rủi ro thấp, những kinh nghiệm thu được sẽ là nền tảng cho bạn chuẩn bị một dự án mới. Mục tiêu của công nghệ yêu cầu là phát triển các yêu cầu chất lượng cao - chứ không phải hoàn hảo – các yêu cầu cho phép bạn xây dựng dự án với một mức độ rủi ro chấp nhận được. Bạn cần dành đủ thời gian cho giai đoạn làm yêu cầu để tối thiểu hóa rủi ro phải làm lại công việc, tạo ra sản phẩm không thể chấp nhận, lịch biểu bị tràn. Cuốn sách này giúp bạn xác định khi nào bạn đạt tới điểm có được các yêu cầu chất lượng và gợi ý một số cách để làm điều đó. LỜI CẢM ƠN Một số bạn hữu đã dành thời gian để xem xét các bản thảo và cho tôi những lời khuyên quý báu. Đặc biệt cảm ơn Kathy Rhode, người đã xem xét tỷ mỷ bản thảo và giúp tôi tưduy, trình bày vấn đề tốt hơn. Các bạn Chris Fahlbusch, Tammy Hoganson, Deependra Moitra, Mike Rebatzke Tôi cũng cảm ơn Steve McConnell, người đã khuyến khích tôi viết một cuốn sách về yêu cầu phần mềm và đã chuyển bản thảo cho biên tập viên Ben Ryan của Microsoft Press. Ben đã giúp tôi làm việc với các biên tập viên khác của nhà xuất bản. Mary Kalbach Barnard của Microsoft Press đã quản lý dự án này và cùng với sự giúp đỡ của Michelle Goodman, đã biên tập từ bản thảo đầu tiên đến bản thảo cuối cùng của cuốn sách. Tôi rất biết ơn một số khách hàng mà tôi tưvấn, đặc biệt là Sandy Browning, Matt DeAthos, Kathy Rhode, Kathy Wallace, những người đã mời tôi tham gia làm việc cùng họ trong các quy trình yêu cầu. Tôi cũng cảm ơn sự đóng góp từ hàng nghìn người tham gia các xêmina về yêu cầu phần mềm của tôi trong những năm qua. Là một nhà tưvấn và một nhà giáo dục, tôi đã học được rất nhiều từ mỗi công ty mà tôi làm việc, từ những người đã tham Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 8
9. gia các xêmina của tôi. Những gì hữu ích thu thập đều được tôi đưa vào cuốn sách này. Mọi thưtừ trao đổi xin gửi cho tôi kwiegers@acm.org. Tôi trân trọng sự đóng góp sâu sắc nhất cho cuốn sách này từ vợ của tôi - Chrish Zambito. Xin mời bạn nghiên cứu cuốn sách và thực hành những gì bạn thu thập được. Chúc bạn thành công! VỀ TÁC GIẢ KARL E. WIEGERS Karl E. Wiegers là nhà tưvấn chính tại Process Impact, một công ty đào tạo và tư vấn quy trình phần mềm có trụ sở tại Portland, Oregon. Ông đã tưvấn và thuyết trình trong các xêmina tại hàng chục công ty vùng Bắc Mỹ. Trước đây, Karl đã làm việc 18 năm tại công ty Eastman Kodak, nơi ông làm công việc của một nhà khoa học nghiên cứu về ảnh, nhà phát triển phần mềm, nhà lãnh đạo quy trình phần mềm và cải tiến quy trình. Karl đã nhận bằng tốt nghiệp đại học ngành hóa học từ Boise State College, bằng cao học và tiến sỹ hóa hữu cơcủa University of Illinois. Ông là thành viên của IEEE, IEEE Computer Society và Hiệp hội máy tính Mỹ (ACM). Karl là tác giả của cuốn sách đoạt giải thưởng Năng suất phát triển phần mềm (Software Development Productivity) - cuốn Tạo lập một nền văn hóa công nghệ phần mềm (Creating a Software Engineering Culture) do Dorst House xuất bản năm 1996. Ông cũng là tác giả của hơn 150 bài báo về nhiều khía cạnh của khoa học máy tính, hóa học và lịch sử quân sự. Ông đồng thời là biên tập viên bán thời gian cho tạp chí Software Devlopement, là một thành viên trong ban biên tập của tạp chí IEEE Software. Khi không làm việc, ông chơi ghita với tay ghita Gibson Les Paul, đua trên chiếc mô tô Suzuki VX800 của mình, nghiên cứu lịch sử quân sự, nấu nướng và nhấm nháp rượu vang với vợ và con mèo đen Gremlin của họ. Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 9
10. MỤC LỤC PHẦN I – YÊU CẦU PHẦN MỀM: CÁI GÌ VÀ TẠI SAO 1. Cơbản về yêu cầu phần mềm 2. Yêu cầu phần mềm từ quan điểm của khách hàng 3. Các thực hành hiệu quả cho công nghệ yêu cầu 4. Cải tiến quy trình yêu cầu của bạn 5. Yêu cầu phần mềm và quản lý rủi ro PHẦN II – PHÁT TRIỂN YÊU CẦU PHẦN MỀM 6. Thiết lập tầm nhìn và phạm vi của dự án 7. Tìm kiếm tiếng nói của khách hàng 8. Lắng nghe tiếng nói của khách hàng 9. Tài liệu hoá yêu cầu 10. Một bức tranh đáng giá 1024 lời nói 11. Các thuộc tính của chất lượng phần mềm 12. Giảm rủi ro thông qua làm nguyên mẫu 13. Thiết lập các ưu tiên của yêu cầu 14. Kiểm tra chất lượng yêu cầu 15. Nhìn xa hơn việc phát triển yêu cầu PHẦN III - QUẢN LÝ YÊU CẦU PHẦN MỀM 16. Các nguyên lý và thực hành quản lý yêu cầu 17. Quản lý đề nghị thay đổi 18. Các liên kết trong chuỗi yêu cầu 19. Công cụ cho quản lý yêu cầu Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 10
11. PHẦN I YÊU CẦU PHẦN MỀM: CÁI GÌ VÀ TẠI SAO Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 11
12. CHƯƠNG 1 CƠBẢN VỀ YÊU CẦU PHẦN MỀM “Xin chào, Phill? Tôi là Maria ở Bộ phận Nguồn nhân lực. Chúng tôi đang có vấn đề về hệ thống nhân lực (employee system) mà anh đã lập trình cho chúng tôi. Một nhân viên vừa mới thay đổi tên của cô ta thành Sparkle Starlight và chúng tôi không thể khiến cho hệ thống chấp nhận tên thay đổi này. Giúp tôi được không?” “Cô ta vừa cưới một gã tên là Starlight à?” “Không, cô ta không cưới chồng, chỉ thay đổi tên thôi,”, Maria đáp. “Đó mới là vấn đề. Hệ thống chỉ chấp nhận ai đó thay đổi tên nếu họ thay đổi tình trạng hôn nhân của mình.” “Ồ, tôi chưa bao giờ nghĩ rằng có ai đó lại thay đổi tên của mình. Tôi không thấy chị nói với tôi về việc này khi chúng ta trao đổi với nhau về hệ thống trước đây. Đó là lý do chị không thể nhấn vào hộp thoại Change Name nếu trước đó không nhấn vào hộp thoại Change Marital Status,” Phill nói. Maria nói, “Tôi nghĩ anh biết mọi người đều có thể thay đổi tên của mình một cách hợp pháp bất cứ lúc nào nếu họ thích. Thêm nữa, chúng tôi phải khoá sổ vào thứ 6 tới nhưng Sparkle không thể thanh toán được hoá đơn của cô ấy. Có thể giúp tôi sửa lỗi (bug) này không?” “Đó không phải là lỗi! Tôi không hề biết là chị cần tính năng này. Tôi bận vào vụ hệ thống đánh giá hiệu suất mới rồi. Tôi nghĩ tôi có một số đề nghị thay đổi khác cho hệ thống nhân lực đây,” [tiếng giấy sột soạt], “Đây rồi. Tôi có thể cố định chức năng khoá sổ vào cuối tháng chứ không phải cuối tuần. Xin lỗi nhé. Lần tới, hãy nói những thứ đó cho tôi sớm hơn và làm ơn ghi ra giấy.” “Vậy tôi có thể giúp gì cho Sparkle đây”, Maria vặn hỏi, “Cô ấy không thể thực hiện công việc được nếu không thanh toán được hoá đơn.” “Ồ, Maria, đó không phải lỗi của tôi.” Phill nói. “Nếu cô nói trước với tôi cái vụ thay đổi tên đó thì mọi việc đã xuôi chèo mát mái. Cô không thể xử lý tôi vì tôi không đọc được ý nghĩ của cô.” Giận dữ Maria nặng lời, “Ồ, thế cơđấy, đây chính là lý do làm tôi ghét máy tính. Hãy gọi lại tôi càng sớm càng tốt để sửa cái này.” Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 12
13. Nếu bạn đã từng trao đổi với khách hàng nhưtrên thì bạn biết khách hàng sẽ rắc rối nhưthế nào nếu phải sử dụng các phần mềm không thể thực hiện được các tác vụcơbản (tác vụ- task, được hiểu là các công việc trước đây là của người dùng những giờđược giao cho máy tính thực hiện, ví dụ tác vụin hóa đơn, tác vụlập báo cáo tài chính - ND). Còn về phía bạn, bạn đã thấy mọi việc rối tinh ra sao nếu nhận được mong muốn của khách hàng đối với hệ thống sau khi hệ thống đã được cài đặt. Cũng thật bực bội nếu bạn phải sửa hệ thống ngay trong khi bạn đang xây dựng hệ thống đúng nhưnhững gì bạn đã được nghe từ lúc đầu. Nhiều vấn đề nảy sinh trong khi phát triển phần mềm có thể có nguồn gốc từ quy trình và từ sự thực hiện các quy trình đó trong việc thu thập, tài liệu hoá, thoả thuận và lựa chọn các yêu cầu phần mềm. Nhưcâu truyện trên, miền thông tin thu thập có thể gồm cả những gì không được nói ra, không được ghi nhận, không được thoả thuận. Khi xây dựng một ngôi nhà, phần lớn trong số chúng ta đều trao đổi với nhà thầu về nhu cầu và mong muốn của chúng ta từ đó ước tính chi phí. Tuy vậy, phần lớn trong số đó lại không làm nhưvậy khi đặt hàng một sản phẩm phần mềm. Khoảng từ 40% đến 60% các lỗi xuất hiện là do không tìm hiểu kỹ bài toán trong khâu yêu cầu (Leffingwell 1997). Nhiều tổ chức vẫn ứng dụng các phương pháp theo kiểu thuận tiện, có sao thì làm vậy (ad hoc) để làm yêu cầu. Kết quả đạt được là một sự vênh nhau giữa cái khách hàng nghĩlà chúng ta sẽ xây dựng cho họ và cái mà chúng ta nghĩchúng ta đang làm cho khách hàng. Do yêu cầu là đầu vào của quy trình sản xuất phần mềm và mọi hoạt động quản lý dự án, nên tất cả những người liên quan cần phải đồng thuận trong một quy trình làm yêu cầu (còn gọi là công nghệ yêu cầu - ND) hiệu quả. Chương này giúp bạn: Hiểu một số khái niệm chính trong việc phát triển yêu cầu phần mềm. Có hiểu biết về một số vấn đề liên quan đến yêu cầu có thể nảy sinh trong một dự án phần mềm. Tìm hiểu về một số đặc tính mà một yêu cầu tuyệt vời hoặc một đặc tả yêu cầu cần phải có. Nhận biết sự khác nhau giữa phát triển yêu cầu và quản lý yêu cầu. Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 13
14. I. ĐỊNH NGHĨA YÊU CẦU PHẦN MỀM (SOFTWARE REQUIREMENTS DEFINED) Một khó khăn đối với ngành công nghiệp phần mềm là thiếu các định nghĩa chung về các khái niệm mà chúng ta sử dụng để mô tả các công việc, một trong số đó là định nghĩa khái niệm “requirement”. Định nghĩa này cần đáp ứng cho nhiều đối tượng liên quan khác nhau như: developers, customers, others (người phát triển, khách hàng, người khác – Một số thuật ngữ sẽ được để nguyên tiếng Anh – ND). The IEEE Standard Glossary of Software Engineering Technology (1997) định nghĩa một yêu cầu là: (1)Một quy ước (condition) hoặc một công năng (capability) của sản phẩm phần mềm cần thiết cho người dùng để giải quyết một vấn đề hoặc để đạt được một mục tiêu. (2)Một quy ước hoặc một công năng cần phải thỏa mãn hoặc cần phải có của một hệ thống hoặc một thành phần hệ thống (system component) nhằm đáp ứng một hợp đồng, một tiêu chuẩn, một đặc tả hoặc một tài liệu bắt buộc khác. (3)Một sự diễn giải (representation) được ghi thành tài liệu của một quy ước hoặc một công năng theo 1 hoặc 2. 1. MỘTSỐ DIỄN GIẢI VỀ “YÊU CẦU” (SOME INTERPRETATIONS OF “REQUIREMENTS”) Định nghĩa của IEEE bao hàm cả 2 quan điểm về yêu cầu từ người dùng (quan sát hành vi của hệ thống từ bên ngoài) và từ người phát triển (quan sát hệ thống từ bên trong). Một trong các yếu tố quan trọng của requirements là cần được tài liệu hoá. Tôi đã làm việc trong một dự án mà tại đó developers bị quay nhưchong chóng. Khách hàng chính phát hoảng khi người phân tích yêu cầu mới đến và nói: “Chúng tôi cần trao đổi về yêu cầu của anh.” Khách hàng phản ứng lại: “Tôi đã đưa cho người tiền nhiệm của anh yêu cầu rồi.” Thực tế thì không có yêu cầu nào được tài liệu hoá, vì vậy mỗi người phân tích mới đã phải bắt đầu từ một đống lộn xộn. Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 14
15. Thường thì bạn đã có “yêu cầu” rồi nếu bạn có được các emails, voice-mails, các ghi chú, các cuộc gặp gỡ ngắn, các tập hợp giấy tờ linh tinh từ các cuộc họp với người dùng. Một định nghĩa khác gợi ý rằng yêu cầu là “các phát biểu về nhu cầu (need) của người dùng làm điểm xuất phát cho sự phát triển một chương trình hoặc một hệ thống” (Jones 1994). Chuyên gia về yêu cầu Alan Davis (1993) đã mở rộng khái niệm này thành “một nhu cầu của người dùng hoặc một đặc tính, một chức năng, một thuộc tính cần thiết của một hệ thống có thể được hiểu từ một vị trí bên ngoài hệ thống đó”. Các định nghĩa này nhấn mạnh cái mà sản phẩm phải cung cấp thay vì sản phẩm sẽ được làm nhưthế nào từ góc nhìn của người thiết kế và thi công. Định nghĩa sau đi xa hơn: từ nhu cầu người dùng tới các đặc tính (characteristic) của hệ thống (Sommerville and Sawyer 1997): Yêu cầu là một đặc tả về cái phải được thi công. Chúng là các mô tả về hành vi của hệ thống phải nhưthế nào, hoặc về một thuộc tính của hệ thống phải nhưthế nào. Yêu cầu có thể là một ràng buộc về quy trình phát triển của hệ thống. Các định nghĩa đa dạng trên chỉ ra rằng không có cách hiểu sáng sủa, không nhập nhằng về khái niệm “yêu cầu”. Yêu cầu thật sự thường tồn tại trong tâm trí con người.Bất cứ hình thức tài liệu hoá nào về yêu cầu (ví dụ đặc tả yêu cầu) cũng chỉ là một mô hình, một sự trình bày ra bên ngoài về yêu cầu mà thôi (Lawrence 1998). Chúng ta cần đảm bảo rằng tất cả những người liên quan của dự án đều có một cách hiểu chung về các khái niệm được dùng để mô tả các yêu cầu. 2. CÁC MỨC CỦA YÊU CẦU (LEVELS OF REQUIREMENTS) Các định nghĩa sau mà tôi sẽ sử dụng đối với một số khái niệm chung, bạn sẽ thường gặp chúng trong lĩnh vực công nghệ yêu cầu. Yêu cầu phần mềm gồm 3 mức phân biệt – yêu cầu kinh doanh (business requirements, BR), yêu cầu người dùng (user requirements, UR), yêu cầu chức năng (functional requirements, FR) hoặc yêu cầu phi chức năng (NFR). Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 15
16. BR biểu diễn các mục tiêu ở mức cao của tổ chức hoặc của khách hàng đối với hệ thống. Chúng được trích ra (capture) từ một tài liệu mô tả tầm nhìn (vision) và phạm vi (scope) của dự án. UR mô tả các tác vụ (task) mà người dùng phải hoàn thành bằng cách sử dụng hệ thống nhưmột công cụ làm việc. Chúng được trính ra trong các mô tả tình huống sử dụng (use case) hoặc kịch bản sử dụng. FR định nghĩa chức năng của phần mềm mà người phát triển cần phải đưa vào sản phẩm để người dùng hoàn thành tác vụ của họ, do đó mà đáp ứng các yêu cầu kinh doanh (BR). Một tính năng (feature) là một tập hợp logic các yêu cầu chức năng có liên quan lẫn nhau nhằm cung cấp cho người dùng khả năng (capability) đáp ứng một yêu cầu kinh doanh. Xem Hình 1-1 về mối quan hệ giữa các mức của yêu cầu. HÌNH 1-1. Quan hệ giữa một số thành phần của yêu cầu phần mềm. FR được tài liệu hoá trong một đặc tả yêu cầu phần mềm (Software requirements specification, SRS), tài liệu này mô tả đầy đủ ở mức có thể Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 16
17. hành vi mong muốn đối với hệ thống bằng một cái nhìn từ bên ngoài. SRS được sử dụng trong phát triển, kiểm thử, đảm bảo chất lượng, quản lý dự án và các công việc liên quan khác của dự án. Đối với các sản phẩm phức tạp, yêu cầu chức năng có thể là tập con của yêu cầu hệ thống, nếu một phần của yêu cầu chức năng đã được định vị thành các software components. Ngoài các FR, SRS còn chứa các yêu cầu phi chức năng. Đó là các tiêu chuẩn, quy định, khế ước mà sản phẩm phải tuân thủ; các mô tả của giao diện ngoài (external interface, nói thêm, giao diện trong là giao diện giữa các hệ thống với nhau); các yêu cầu hiệu suất (performance requirements); các ràng buộc về thiết kế và thi công; các thuộc tính chất lượng. Các ràng buộc (constraints) là các giới hạn được định ra trong miền chọn lựa khả năng của người phát triển khi thiết kế và thi công hệ thống. Các thuộc tính chất lượng là các mô tả về các thuộc tính của sản phẩm theo nhiều khía cạnh quan trọng với người dùng hoặc với người phát triển. Chúng ta lấy một chương trình xử lý từ làm ví dụ về các kiểu yêu cầu khác nhau. Một BR có thể viết: “Người dùng có thể sửa các lỗi chính tả (spelling errors) trong tài liệu một cách hiệu quả”. Nhưvậy, trong tài liệu hướng dẫn sử dụng sản phẩm cần ghi rằng một spelling checker được đưa vào sản phẩm – đó là tính năng đáp ứng BR này. Các UR tương ứng có thể mô tả (use case): “Tìm kiếm các spelling errors (lỗi chính tả) trong tài liệu và quyết định liệu có nên thay thế mỗi mispelled word (từsai chính tả) bằng một từ đúng lựa ra từ một danh sách các từ được gợi ý”. Spelling checker có nhiều yêu cầu chức năng cụ thể nhưtìm kiếm và làm sáng (highlight) một misspelled word, hiển thị một dialog box với các từ thay thế được gợi ý Các nhà quản lý hoặc tiếp thị có thể định nghĩa các yêu cầu kinh doanh cho phần mềm, điều đó giúp công ty của họ hoạt động hiệu quả hơn (đối với các hệ thống thông tin) hoặc thành công trên thị trường (đối với các sản phẩm phần mềm thương mại). Tất cả các yêu cầu người dùng cần phải sóng đôi với các yêu cầu kinh doanh. Các yêu cầu người dùng giúp người phân tích cài đặt một phần chức năng (the bits of functionality) mong muốn trong sản phẩm nhằm giúp người dùng thực hiện tác Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 17
18. vụ của họ. Người phát triển (developers) sử dụng các yêu cầu chức năng để thiết kế các giải pháp thực thi chức năng cần thiết. Chú ý rằng yêu cầu, theo định nghĩa, không bao hàm các chi tiết thiết kế, các chi tiết thi công, thông tin lập kế hoạch dự án, hoặc thông tin kiểm thử. Hãy tách các thông tin đó ra khỏi yêu cầu sao cho yêu cầu chỉ chứa các thông tin hệ thống cần phải làm cái gì. Dự án cũng có thể có các kiểu yêu cầu khác nhau nhưyêu cầu về môi trường phát triển, yêu cầu về phát hành sản phẩm và thích ứng nó với môi trường hỗ trợ. Các kiểu yêu cầu đó có thể ảnh hưởng nghiêm trọng đến sự thành công của dự án nhưng trong cuốn sách này ta không xét đến chúng. II. MỖI DỰ ÁN ĐỀU CÓ YÊU CẦU (EVERY PROJECT HAS REQUIREMENTS) Fredrick Brooks xác định vai trò đặc biệt quan trọng của quy trình yêu cầu đối với các dự án phần mềm trong bài luận kinh điển năm 1987 của ông, “No Silver Bullet: Essence and Accidents of Software Engineering”: Việc duy nhất khó khăn khi làm một hệ thống phần mềm là quyết định chính xác cái cần phải xây dựng. Không có công việc nào là khó khăn nhưthiết lập các yêu cầu kỹ thuật chi tiết, gồm tất cả giao diện với người dùng, giao diện với máy móc (machines) và với các hệ thống phần mềm khác. Không có công việc nào ảnh hưởng xấu đến hệ thống bằng công việc này nếu nó bị thực hiện sai. Không có công việc nào là khó khăn hơn công việc này nếu phải chỉnh sửa lại sau. Mỗi hệ thống phần mềm có người dùng của riêng nó. Thời gian để tìm hiểu nhu cầu của họ là một khoản đầu tưthen chốt khiến dự án thành công. Nhận định này là hiển nhiên đối với các ứng dụng đầu cuối thương mại, các hệ thống thông tin doanh nghiệp, các sản phẩm chứa các phần mềm nhúng. Nếu chúng ta, với tưcách là những người phát triển, không viết ra các yêu cầu để khách hàng có thể thảo luận về nó, thì làm sao chúng ta biết khi nào thì dự án thực hiện xong. Chúng ta có thể đáp ứng nhưthế nào cho khách hàng nếu không biết cái gì quan trọng đối với họ. Thậm chí đối với ngay cả các phần mềm phi thương mại thì các yêu cầu cũng cần phải được hiểu cho rõ. Ví dụ các thưviện phần mềm, các components, các tools được tạo ra cho các nhóm phát triển sử dụng. Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 18
19. III. KHI CÁC YÊU CẦU XẤU XẢY RA VỚI CON NGƯỜI TỐT (WHEN BAD REQUIREMENTS HAPPEN TO NICE PEOPLE) Khi các nhóm dự án không quan tâm đến các quy trình yêu cầu thì họ sẽ khiến dự án lâm vào tình thế nguy hiểm, sự thành công của dự án là khó đảm bảo. Nếu “thành công” được hiểu là chuyển giao một sản phẩm đáp ứng các mong đợi của người dùng về chức năng, về chất lượng ở mức chi phí đã thoả thuận và trong một thời gian giới hạn. Một số rủi ro về yêu cầu sẽ được thảo luận dưới đây. Chương 5 sẽ thảo luận việc bạn có thể làm gì để tránh các rủi ro yêu cầu. MỘT SỐ RỦI RO TỪ SỰ KHÔNG ĐẦY ĐỦ CỦA QUY TRÌNH YÊU CẦU (SOME RISKS FROM INADEQUATE REQUIREMENTS PROCESS) Nếu các kiểu người dùng không được tính đến đầy đủ trong khi làm yêu cầu thì hệ thống có thể sẽ không được chấp nhận. Việc phát sinh các yêu cầu không chính thức (creeping user requirements) góp phần làm hỏng và giảm chất lượng sản phẩm. Các yêu cầu nhập nhằng dẫn tới tiêu phí nhiều thời gian để làm lại. “Sự mạ vàng” (gold – plating) của người phát triển và người dùng sẽ thêm vào hệ thống các tính năng (features) không cần thiết. Các đặc tả tối thiếu dẫn tới các yêu cầu chính bị thiếu hụt (missing key requirements). Bỏ qua nhu cầu của một số kiểu người dùng nào đó sẽ dẫn tới sự không hài lòng của khách hàng. Các yêu cầu được định nghĩa không đầy đủ khiến đòi hỏi lập kế hoạch dự án chính xác và giám sát là không thể. Các kiểu người dùng không được tính đến đầy đủ (Insufficient user involvement) Khách hàng thường không hiểu tại sao việc thu thập yêu cầu và đảm bảo chất lượng yêu cầu lại khó khăn đến thế. Người phát triển không thể nhấn mạnh đến sự tham gia của người dùng (user involvement), hoặc cũng có thể là làm việc với người dùng thì không vui nhưviết code, hoặc cũng có thể họ nghĩ họ đã biết cái người dùng cần. Trong một số trường hợp, trao đối trực tiếp với những người sẽ sử Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 19
20. dụng sản phẩm không phải là điều dễ dàng, trong khi đó những người đại diện của khách hàng không phải bao giờ cũng hiểu được chính xác cái mà người dùng thật sự cần. Không có sự thay thế nào cho sự tham gia của các đại diện người dùng một cách trực tiếp trong nhóm dự án ngay từ sớm và kết hợp với họ liên tục trong suốt quy trình phát triển. Việc phát sinh các yêu cầu không chính thức (Creeping user requirements) Do các yêu cầu liên tục tiến hoá khi phát triển dự án, nên dự án luôn có thể vượt khỏi các lịch biểu và ngân sách đã định. Các dự án nhưvậy không phải luôn dựa trên sự hiểu biết thực tế về kích thước và độ phức tạp của các yêu cầu, các rủi ro, năng suất làm việc của dự án, việc sinh ra các yêu cầu không chính thức có thể gây ra các vấn đề to lớn. Vấn đề có thể phụ thuộc một phần vào đề nghị thay đổi yêu cầu của người dùng, phụ thuộc một phần vào cách những người phát triển đáp ứng các yêu cầu và chỉnh sửa mới. Để quản lý việc sinh ra các yêu cầu không chính thức, chúng ta cần làm sáng sủa các báo cáo về tầm nhìn, phạm vi, mục tiêu, giới hạn và các tiêu chuẩn thành công của dự án. Báo cáo này sẽ được sử dụng nhưmột khung tham chiếu mỗi khi một tính năng mới được đề nghị, hoặc các thay đổi yêu cầu được đề xuất. Một quy trình kiểm soát thay đổi được thiết kế tốt bao gồm việc phân tích ảnh hưởng của mỗi thay đổi được đề xuất, việc này sẽ giúp các người liên quan đề ra quyết định liệu thay đổi đó có được chấp nhận hay không trong sự cân bằng các chi phí, thời hạn, nguồn lực hoặc các tính năng khác. Do các thay đổi có thể lan truyền trên toàn bộ sản phẩm đang được phát triển nên kiến trúc của hệ thống có thể bị phá vỡ dần dần. Các miếng vá sẽ khiến chương trình khó khăn hơn để hiểu và bảo trì. Sự liên quan lẫn nhau của các mã thêm vào (insertion of additional code) có thể gây ra các vấn đề đối với nguyên tắc thiết kế hệ thống bền vững. Nếu bạn có thể xác định sớm các tính năng có khả năng sẽ thay đổi theo thời gian thì bạn có thể thiết lập một kiến trúc bền vững cho hệ thống, do vậy mà kiểm soát được tốt hơn sự thay đổi. Các thay đổi yêu cầu nếu được thực hiện thông qua thay đổi thiết kế, thay vì phát hành các bản vá lỗi, thì sẽ giúp kiểm soát tốt hơn chất lượng sản phẩm. Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 20
21. Các yêu cầu nhập nhằng (Ambigous Requirements) Sự nhập nhằng là khó khăn to lớn đối với việc đặc tả yêu cầu (Lawrence 1996). Sự nhập nhằng khiến cho những người đọc các báo cáo mô tả yêu cầu đi đến những cách hiểu khác nhau về cái mà phần mềm phải làm. Một dấu hiệu khác nữa của sự nhập nhằng là ngay cả một người đọc cũng có thể diễn giải một yêu cầu theo nhiều cách khác nhau. Sự nhập nhằng dẫn tới các kỳ vọng (expectation) khác nhau từ người liên quan, một số trong họ sẽ ngạc nhiên về những gì được chuyển giao. Các yêu cầu nhập nhằng dẫn tới lãng phí thời gian khi các nhà phát triển cài đặt một giải pháp cho một vấn đề sai, khi các nhà kiểm thử kỳ vọng sản phẩm có những hành vi khác với những gì mà các nhà phát triển đã xây dựng. Trước đây, một nhà kiểm thử hệ thống đã nói với tôi rằng nhóm kiểm thử của cô thường diễn giải sai các yêu cầu, vì vậy đã phải viết lại nhiều test cases và lặp đi, lặp lại nhiều kiểm thử. Kết quả không thể tránh được của sự nhập nhằng là phải làm lại công việc đã làm. Các công việc làm lại có thể tiêu tốn 40% tổng chi phí phát triển, 70% - 80% việc sửa lại được quy cho các lỗi yêu cầu (Leffingwell 1997). Một cách để truy tìm sự nhập nhằng là có một nhóm đại diện cho nhiều quan điểm khác nhau thanh tra (inspect) các yêu cầu. Nếu mỗi người trong nhóm đó diễn giải một yêu cầu theo nhiều cách khác nhau thì đã có sự nhập nhằng trong báo cáo yêu cầu. Các kỹ thuật khác nhau để phát hiện sự nhập nhằng được mô tả bởi Gause và Weinberg (1989) trong phần sau của chương này. Các tính năng không cần thiết (Unnecessary Features) Mạ vàng (gold – plating) được hiểu là khuynh hướng một số nhà phát triển thêm một chức năng mới không có trong đặc tả yêu cầu nhưng họ lý giải rằng “người dùng sẽ thích nó”. Thường thì người dùng không tìm kiếm chức năng này và nguồn lực tiêu tốn để cài đặt nó đã bị lãng phí. Một cách làm mà những người phát triển thích hơn so với chỉ đơn giản thêm các tính năng mới là họ giới thiệu với khách hàng các ý tưởng, các lựa chọn và các cách tiếp cận sáng tạo nhằm giải quyết vấn đề của khách hàng. Quyết định về chức năng nào được thêm vào sẽ được Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 21
22. tính toán cân bằng giữa điều khách hàng muốn và sự xem xét, cân nhắc về tính khả thi kỹ thuật, khung thời gian. Để tối thiểu hoá nguy cơmạ vàng, bạn cần giám sát tất cả các tính năng được thêm vào, mỗi tính năng cần phải có lý do chính đáng để được chấp nhận. Đặc tả tối thiểu (Minimal Specification) Đôi khi, khách hàng và các bên khác nhau (marketing, quản lý) không hiểu được taị sao phải nhấn mạnh các yêu cầu là quan trọng. Để tạo ra một đặc tả tối thiểu, có lẽ không gì hơn là vạch ra các ý tưởng về sản phẩm trên một tờ giấy mỏng và yêu cầu các nhà phát triển làm mịn, bổ sung nó khi dự án tiến triển trên thực tế. Một dấu hiệu xấu cuả việc này là các nhà phát triển viết các yêu cầu sau khi hoàn tất xây dựng sản phẩm. Cách làm này có thể thích hợp với các sản phẩm có tính cách thăm dò cao, hoặc khi mà các yêu cầu phải thật sự mềm dẻo (McConnell 1996). Trong phần lớn các trường hợp, cách làm này khiến các nhà phát triển thất bại (người có thể phải làm việc dưới các giả thiết sai và trong một định hướng hạn chế) và khách hàng thấy mình bị làm phiền (người nhận sản phẩm nhưhọ đã mường tượng). Bỏ qua nhu cầu của một số kiểu người dùng (Overlooked User Classes) Phần lớn các sản phẩm được sử dụng bởi các nhóm người khác nhau, họ có thể sử dụng các tập con tính năng khác nhau, có tần suất sử dụng khác nhau, có kinh nghiệm và trình độ khác nhau. Nếu bạn không xác định tất cả các kiểu người dùng chính – các lớp người dùng (user classes) - của sản phẩm ngay từ sớm thì sẽ có ai đó trong số khách hàng không hài lòng khi sản phẩm được chuyển giao. Ví dụ, các xử lý sử dụng menu là không hiệu quả đối với những người dùng chuyên nghiệp, trong khi các câu lệnh và các phím tắt lại làm những người sử dụng không thường xuyên cảm thấy bối rối. Lập kế hoạch không chính xác (Inaccurate Planning) “Đây là ý tưởng của tôi về một sản phẩm mới; bạn có thể cho tôi biết ý tưởng này khi nào thì được thực hiện?”. Nhiều nhà phát triển phải đối mặt với vấn đề khó khăn này. Sự thiếu hiểu biết về yêu cầu sẽ dẫn tới các ước lượng quá lạc quan về dự án. Năm nguyên nhân hàng đầu đã được tổng kết về các ước lượng chi phí phần Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 22
23. mềm xa thực tế liên quan đến yêu cầu là: thay đổi yêu cầu thường xuyên, thiếu yêu cầu, truyền thông không đầy đủ về yêu cầu cho người dùng, đặc tả sơsài về yêu cầu, phân tích yêu cầu không đầy đủ (Davis 1995). IV. LỢI ÍCH TỪ MỘT QUY TRÌNH YÊU CẦU CHẤT LƯỢNG CAO (BENEFITS FROM A HIGH – QUALITY REQUIREMENTS PROCESS) Các tổ chức sử dụng các quy trình công nghệ yêu cầu hiệu quả có thể vui lòng với nhiều lợi ích thu được. Có lẽ phần thưởng lớn nhất là giảm được các công việc phải làm lại trong giai đoạn phát triển và giai đoạn bảo trì dài. Boehm (1981) phát hiện ra rằng việc sửa một lỗi yêu cầu sau khi sản phẩm đã được phát hành tốn kém gấp 68 lần so với sửa yêu cầu đó ngay trong giai đoạn yêu cầu. Các nghiên cứu gần đây cho biết yếu tố khuếch đại chi phí này có thể là 200 lần. Hiệu quả của việc làm các yêu cầu chất lượng cao ngay từ đầu không phải là rõ ràng với nhiều người, họ chỉ đơn giản cho rằng thời gian tiêu phí cho giai đoạn yêu cầu sẽ làm chậm thời điểm bàn giao sản phẩm cho khách hàng. Quy trình yêu cầu hiệu quả nhấn mạnh cách tiếp cận hợp tác khi xây dựng sản phẩm, quy trình này liên quan đến nhiều người liên quan khác nhau của dự án. Tập hợp các yêu cầu cho phép nhóm dự án hiểu tốt hơn thị trường của sản phẩm, một yếu tố thành công then chốt của bất cứ dự án nào. Cuối cùng, các yêu cầu được tài liệu hoá và không nhập nhằng làm thuận tiện tối đa đối với việc kiểm thử hệ thống và tăng cơhội chuyển giao một sản phẩm chất lượng cao đáp ứng mong đợi của tất cả những người liên quan. V. ĐẶC TÍNH CỦA CÁC YÊU CẦU TUYỆT VỜI (CHARACTERISTICS OF EXCELLENT REQUIREMENTS) Các đặc tính mà một báo cáo yêu cầu tốt cần tuân theo sẽ được thảo luận ở đây (Davis 1993; IEEE 1998). Sự soát xét cẩn thận SRS bởi những người liên quan đại diện cho các góc nhìn khác nhau là cách tốt nhất để xác định liệu các yêu cầu có đầy đủ các đặc tính cần thiết hay không. Nếu bạn lưu giữ các đặc tính đó trong tâm trí khi viết và soát xét các yêu cầu thì bạn sẽ có một thiết kế yêu cầu tốt hơn (mặc dù chả bao giờ hoàn hảo cả). Trong chương 9, bạn sẽ sử dụng các đặc tính này để tìm kiếm các vấn đề với một số báo cáo yêu cầu sao cho bạn có thể cải tiến chúng. Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 23
24. 1. CÁC ĐẶC TÍNH CỦA LỜI THỂ HIỆN YÊU CẦU (REQUIREMENT STATEMENT CHARACTERISTICS) Đầy đủ (Complete) Mỗi yêu cầu cần mô tả đầy đủ chức năng được chuyển giao. Nó phải chứa tất cả các thông tin cần thiết để nhà phát triển thiết kế và thi công chức năng này. Đúng đắn (Correct) Mỗi yêu cầu cần mô tả chính xác chức năng được xây dựng. Sự đảm bảo cho tính đúng đắn đó là tham chiếu đến nguồn của yêu cầu, đó có thể là khách hàng hoặc một đặc tả yêu cầu hệ thống mức cao hơn. Một yêu cầu phần mềm mà xung đột với một yêu cầu hệ thống tương ứng thì là không đúng đắn. Chỉ sự trình bày của người dùng mới có thể xác định tính đúng đắn của yêu cầu người dùng, điều đó cho biết tại sao khi soát xét yêu cầu ta cần sự có mặt của chính người dùng hoặc người đại diện của họ. Soát xét yêu cầu mà không có mặt người dùng có thể khiến những người soát xét nói: “Điều này không có ý nghĩa. Đó có thể là suy diễn.” Khả thi (Feasible) Khả thi có nghĩa là thực thi mỗi yêu cầu trong các khả năng và giới hạn đã biết của hệ thống và môi trường hoạt động của hệ thống. Để tránh các yêu cầu không khả thi, cần một thành viên của nhóm dự án làm việc với các nhà marketing hoặc các nhà phân tích yêu cầu trong quá trình xử lý yêu cầu (elicitation process). Người này sẽ đánh giá về tính khả thi của các yêu cầu về mặt kỹ thuật hoặc các yêu cầu có thể thực thi nhưng với một chi phí lớn. Cần thiết (Necessary) Mỗi yêu cầu cần phải tài liệu hoá một cái gì đó mà khách hàng thật sự cần hoặc một hệ thống khác bên ngoài cần. Một cách khác để xác nhận “tính cần thiết” là yêu cầu đó được đề xuất từ một bên mà bạn biết rất rõ rằng anh ta có thầm quyền đề ra yêu cầu. Được xếp thứ tự ưu tiên (Prioritized) Gán một thứ tự ưu tiên cho mỗi yêu cầu, tính năng (feature), hoặc use-case để có thể hình dung lịch trình phát hành các phiên bản của sản phẩm. Nếu tất cả các yêu Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 24
25. cầu được coi là quan trọng nhưnhau thì quản trị dự án sẽ không xác định được cách thức thi công khi một yêu cầu mới phát sinh ngay trong quá trình thi công của dự án, anh ta sẽ không kiểm soát được ngân sách, lịch biểu và nhân lực của dự án. Chương 13 sẽ thảo luận về thứ tự ưu tiên chi tiết. Không nhập nhằng (Unambigous) Tất cả những ai khi đọc bản báo cáo yêu cầu đều có cùng một cách hiểu, một cách diễn giải nhất quán về nội dung của các yêu cầu. Do ngôn ngữ tự nhiên là có tính nhập nhằng cao nên viết một yêu cầu rõ ràng, cụ thể, đơn nghĩa không phải là dễ. Cách hiệu quả để loại bỏ tính nhập nhằng là mô tả các báo cáo yêu cầu bằng các ngôn ngữ hình thức nhưuse-case chẳng hạn, qua các kịch bản sử dụng cụ thể. Có thể kiểm tra (Verifiable) Hãy kiểm tra mỗi yêu cầu để xem liệu bạn có thể nghĩ ra một số lượng nhỏ các phép tests hoặc sử dụng một cách tiếp cận kiểm tra khác nhưthanh tra (inspection) hoặc chứng minh (demonstration) để biết liệu yêu cầu đó đã được cài đặt hợp lệ trong sản phẩm hay không. Nếu một yêu cầu không thể kiểm tra thì xác định liệu nó có được cài đặt đúng đắn hay không sẽ trở thành vấn đề gây tranh cãi. Các yêu cầu không nhất quán, không khả thi hoặc nhập nhằng thì cũng không thể kiểm tra được. 2. CÁC ĐẶC TÍNH CỦA ĐẶC TẢ YÊU CẦU (REQUIREMENT SPECIFICATION CHARACTERISTICS) Đầy đủ (Complete) Không yêu cầu hoặc thông tin cần thiết nào bị mất. Các yêu cầu bị mất rất khó phát hiện do sự “vô hình” (invisible) của chúng. Tập trung vào các tác vụ của người dùng thay vì tập trung vào các chức năng hệ thống sẽ giúp bạn tránh được sự không đầy đủ đó. Nếu bạn biết bạn thiếu một thông tin nào đó, hãy sử dụng TBD (“to be determined”) nhưlà một dấu hiệu tiêu chuẩn (standard flag) để đánh dấu các “nếp gẫy” (gaps) đó. Hãy phân giải (resolve) tất cả các TBDs trước khi tiến hành xây dựng. Nhất quán (Consistent) Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 25
26. Các yêu cầu nhất quán không xung đột với các yêu cầu phần mềm khác hoặc các yêu cầu cấp cao hơn (hệ thống hoặc kinh doanh). Tất cả các mâu thuẫn trong yêu cầu cần phải được phân giải trước khi quá trình phát triển diễn ra. Bạn có thể không biết một yêu cầu đơn nhất (single requirement) nào đó là đúng đắn cho đến tận khi bạn tiến hành một số nghiên cứu nào đó về yêu cầu này. Có thể sửa chữa (Modifiable) Bạn cần nghiên cứu lại SRS khi cần thiết và duy trì thông tin diễn biến thay đổi của mỗi yêu cầu. Điều này đòi hỏi mỗi yêu cầu được dán nhãn duy nhất và được diễn giải riêng rẽ với các yêu cầu khác sao cho mỗi yêu cầu đều được tham chiếu chính xác. Mỗi yêu cầu chỉ được xuất hiện duy nhất 1 lần trong SRS để tránh sự không nhất quán giữa các thể hiện (instance) của cùng 1 yêu cầu tại những nơi khác nhau. Một bảng nội dung (table of contents), một index, một danh sách tham chiếu chéo (cross – reference listing) sẽ làm SRS dễ sửa chữa hơn. Có thể theo vết (Traceable) Bạn cần phải liên kết các yêu cầu tới nguồn phát sinh của nó, tới các phần tử thiết kế, mã nguồn, các test cases thực thi và kiểm tra sự đúng đắn trong việc thi công các yêu cầu. Các yêu cầu có thể theo vết được gán nhãn duy nhất và được viết theo một cách có cấu trúc, chi tiết và được thuyết minh đầy đủ. Chương 18 sẽ tập trung trình bày nội dung này. VI. PHÁT TRIỂN VÀ QUẢN LÝ YÊU CẦU (REQUIREMENTS DEVELOPMENT AND MANAGEMENT) Sự tối nghĩa của thuật ngữ yêu cầu khiến cho có nhiều cách hiểu khác nhau và cách làm khác nhau đối với việc thu thập và xử lý yêu cầu. Một số tác giả gọi toàn bộ quy trình yêu cầu là “công nghệ yêu cầu” (requirement engineering), một số khác lại gọi là “quản lý yêu cầu” (requirement management). Thường thì người ta chia nhỏ toàn bộ quy trình này ra thành phát triển yêu cầu (requirements development) (trình bày trong Phần II) và quản lý yêu cầu (requirements management) (trình bày trong Phần III), nhưthể hiện ở Hình 1-2. Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 26
27. HÌNH 1-2. Phân cấp công nghệ yêu cầu. Phát triển yêu cầu cũng có thể được chia nhỏ thành suy luận, phân tích, đặc tả, kiểm tra (elicitation, analysis, specification, verification) (Thayer and Dorfman 1997). Tất cả các nhánh công việc con đó bao trọn toàn bộ các hoạt động thu thập, đánh giá, tài liệu hoá yêu cầu của một phần mềm. Các hoạt động phát triển yêu cầu gồm: Xác định các lớp người dùng kỳ vọng (expected user classes) của sản phẩm. Suy luận nhu cầu (needs) từ các cá nhân đại diện cho mỗi lớp người dùng đó. Tìm hiểu tác vụ của người dùng hiện tại, các mục tiêu và nhu cầu kinh doanh được các tác vụ đó trợ giúp. Phân tích thông tin nhận được từ người dùng để phân loại các nhu cầu tác vụ của họ với các yêu cầu chức năng, các quy tắc nghiệp vụ (business rules), các thuộc tính chất lượng, các giải pháp được đề nghị, thông tin xa lạ khác. Phân chia (partitioning) các yêu cầu mức hệ thống thành các hệ thống con cơbản (major subsystems) và phân bổ (allocating) một số yêu cầu thành các software components. Tìm hiểu về tầm quan trọng tương đối của các thuộc tính chất lượng. Đàm phán về các ưu tiên trong thi công hệ thống. Biến đổi (translate) các nhu cầu người dùng đã tập hợp được thành các đặc tả và mô hình (specifications and models). Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 27
28. Soát xét các đặc tả yêu cầu để đảm bảo một cách hiểu chung về các yêu cầu đã được định vị (stated requirements) và sửa chữa bất cứ vấn đề gì trước khi nhóm phát triển chấp nhận chúng. Quản lý yêu cầu được hiểu là “thiết lập và duy trì một thoả thuận với khách hàng về các yêu cầu của dự án phần mềm” (CMU/SEI 1995). Tuy nhiên sự chấp nhận của khách hàng cũng mới chỉ chiếm một nửa điều kiện của thông qua yêu cầu. Các nhà phát triển cũng phải thoả thuận để chấp nhận chúng và xây dựng sản phẩm tương ứng. Thông thường các hoạt động quản lý yêu cầu bao gồm: Định nghĩa ranh giới (baseline) của hoạt động xử lý yêu cầu (ranh giới giữa phát triển và quản lý yêu cầu). Soát xét các thay đổi yêu cầu được đề nghị và đánh giá các ảnh hưởng của mỗi thay đổi đó trước khi quyết định có chấp nhận sự thay đổi đó hay không. Kết hợp các thay đổi yêu cầu đã được chấp nhận đó vào dự án theo một cách được kiểm soát. Bám sát kế hoạch dự án với sự thay đổi của các yêu cầu. Đàm phán về các cam kết mới căn cứ vào các ảnh hưởng được ước lượng của các yêu cầu thay đổi. Lần vết mỗi yêu cầu bị thay đổi đến các thiết kế tương ứng, mã nguồn, kịch bản kiểm thử. Hiệu chỉnh (tracking) trạng thái của các yêu cầu và các hoạt động thay đổi trên toàn bộ dự án. Hình 1-3 thể hiện sự khác nhau giữa phát triển yêu cầu và quản lý yêu cầu (Xem hình này hiểu kỹ hơn khái niệm requirements baseline). Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 28
29. HÌNH 1-3. Biên phân chia giữa phát triển yêu cầu và quản lý yêu cầu. Các bước tiếp theo Viết ra bất cứ vấn đề gì liên quan đến yêu cầu mà bạn đang phải đối mặt trong các dự án hiện tại và trước đây của bạn. Hãy chỉ ra vấn đề đó thuộc loại phát triển hay quản lý yêu cầu. Hãy xác định các ảnh hưởng gây ủa bởi mỗi vấn đề và nguyên nhân gốc của mỗi vấn đề. Hãy tổ chức một cuộc thảo luận với các thành viên trong nhóm của bạn và những người liên quan khác (khách hàng, marketing, các nhà quản trị dự án) về các vấn đề liên quan đến yêu cầu từ các dự án hiện tại và trước đây của bạn, về các ảnh hưởng và nguyên nhân gốc của chúng. Hãy giải thích với những người tham gia rằng họ phải đối mặt với các khó khăn nếu họ muốn nắm bắt chúng. Họ sẵn sàng chứ? Hãy sắp xếp một lớp học trong 1 ngày về yêu cầu cho nhóm của bạn. Nhóm đó gồm khách hàng chính, nhân viên marketing, các nhà quản lý, hãy làm bất cứ cái gì cần thiết để họ ngồi lại cùng nhau và học lớp này. Lớp học sẽ cung cấp cho họ một danh sách từ vựng chung, một cách hiểu chung về các vấn đề của việc phát triển và quản lý yêu cầu, nhờ vậy họ có thể chỉ mặt, đặt tên các thách thức mà họ cần vượt qua. Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 29
30. CHƯƠNG 2 YÊU CẦU TỪ GÓC NHÌN CỦA KHÁCH HÀNG Gerhard là một nhà quản lý cấp cao của Consoto Pharmaceuticals, anh có một cuộc gặp làm việc với Cynthia, nhà quản lý mới của nhóm phát triển hệ thống thông tin của Contoso. “Chúng ta cần xây dựng một hệ thống thông tin giám sát hoá chất (chemical-tracking information system, CTIS) cho Contoso,” Gerhard bắt đầu. “Hệ thống phải cho phép giám sát tất cả các chai hóa chất mà chúng ta có trong kho hoặc trong các phòng thí nghiệm. Nhưvậy, các nhà hoá học có thể biết hoá chất họ muốn dùng còn không và còn ở đâu thay vì khi nhu cầu xuất hiện thì lại đi mua chai mới. Văn phòng Sức khoẻ và An toàn cũng phải thực hiện các báo cáo về việc sử dụng hoá chất để gửi chính phủ liên bang. Nhóm của cô có thể giúp chúng tôi xây dựng phần mềm này trong 5 tháng chứ, nghĩa là phần mềm đã sẵn sàng hoạt động ngay khi chúng ta có cuộc kiểm toán tuân thủ đầu tiên?” “Tôi nghĩđó chính là lý do tại sao dự án này quan trọng, Gerhard,” Cynthia trả lời. “Nhưng trước khi tôi có thể cam kết một lịch biểu, tôi cần thu thập một số yêu cầu về hệ thống này đã.” Gerhard lúng túng. “Cô nói sao? Tôi vừa chẳng nói yêu cầu với cô đó thôi.” “Thật sự là anh chỉ vừa nói về một ý tưởng và một số mục tiêu của dự án này,” Cynthia giải thích. “Các yêu cầu kinh doanh mức cao đó (high-level business requirements) không giúp tôi hình dung đủ chi tiết về cái gì cần làm và ước tính thời gian làm trong bao lâu. Tôi muốn có một nhóm kết hợp giữa các phân tích viên hệ thống và các nhà hoá học để hiểu rõ về nhu cầu đối với hệ thống này. Khi đó chúng tôi có thể phác ra chức năng nào là cần thiết nhằm đáp ứng cả mục tiêu kinh doanh và nhu cầu người dùng. Thậm chí anh có vẻ nhưkhông hề cần biết hệ thống này giúp anh nhưthếnào trong việc tiết kiệm được chi phí hoạt động.” Gerhard không hề phải đối mặt với sự phản ứng nhưthế này từ người phát triển hệ thống trước đây. “Các nhà hoá học rất bận rộn,” anh ta phản đối, “họ không có Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 30
31. thời gian để vẽ ra các chi tiết trước khi cô bắt đầu xây dựng hệ thống của mình. Người của cô không làm được việc này sao?” Cynthia cố gắng giải thích lý lẽ của cô trong việc thu thập yêu cầu từ những người sẽ sử dụng hệ thống mới, “Nếu chúng tôi làm những gì mà chúng tôi cho rằng người dùng cần thì chúng tôi không thể làm ra một hệ thống tốt được. Chúng tôi là những nhà phát triển phần mềm, vì vậy chúng tôi không thật sự biết các nhà hoá học cần gì để làm ra hệ thống giám sát hoá chất cho họ được. Tôi đã học được rằng nếu chúng tôi không mất thời gian để tìm hiểu vấn đề trước khi viết mã nguồn thì sẽ không ai hài lòng về sản phẩm phần mềm làm ra.” “Thôi nào, chúng ta không có thời gian cho những việc ấy,” Gerhard khăng khăng ý kiến của mình, “Tôi vừa cho cô yêu cầu rồi. Nào bắt đầu xây dựng hệ thống của cô đi. Hãy nhớ tiến độ tôi yêu cầu đấy.” Cuộc trao đổi trên là điển hình trong ngành công nghiệp phần mềm. Khách hàng đề nghị xây dựng một hệ thống thông tin mới nhưng thường không hiểu tầm quan trọng của việc có được đầu vào từ những người dùng tương lai của hệ thống. Không gì có thể thay thế cho việc thu thập yêu cầu trực tiếp từ những người sẽ sử dụng hệ thống. Một nghiên cứu trên 8380 dự án đã chỉ ra rằng hai nguyên cao nhất khiến dự án bị trục trặc là thiếu thông tin đầu vào từ người dùng và các yêu cầu, đặc tả không đầy đủ (Standish 1995). Nguyên nhân của sự bối rối đối với đa số những người liên quan đến việc xây dựng một hệ thống thông tin là phân biệt sự khác nhau giữa các mức yêu cầu: kinh doanh, người dùng, chức năng (business, user, functional). Gerhard đã xác định một số yêu cầu kinh doanh, nhưng anh ta không thể mô tả được yêu cầu người dùng vì anh ta không phải là người sử dụng của hệ thống này. Những người dùng tiềm năng mới có thể mô tả các tác vụ mà họ cần phải làm với sự trợ giúp của hệ thống, nhưng họ lại không thể xác định tất cả các yêu cầu chức năng cụ thể cần phải được cài đặt để cho phép họ hoàn thành các tác vụ đó. Chương này làm rõ mối quan hệ giữa khách hàng và nhà phát triển, quan hệ đóng vai trò then chốt trong sự thành công của một dự án phần mềm. Tôi đề xuất một Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 31
32. Dự luật Yêu cầu về Quyền của Khách hàng Phần mềm (Requirements Bill of Rights for Software Customers) và một Dự luật Yêu cầu về Trách nhiệm của Khách hàng Phần mềm (Requirements Bill of Responsibilities for Software Customers) tương ứng nhằm nhấn mạnh tầm quan trọng của khách hàng (và người dùng nói riêng) trong quy trình phát triển yêu cầu. I. AI LÀ KHÁCH HÀNG? (WHO IS THE CUSTOMER?) Trong nghĩa rộng nhất của nó, một khách hàng là một cá nhân hoặc một tổ chức được hưởng trực tiếp hoặc gián tiếp lợi ích từ việc sử dụng một sản phẩm. Khách hàng phần mềm gồm tất cả những người liên quan đến dự án, đó là những người thanh toán tiền mua phần mềm, chọn lựa, đặc tả, sử dụng phần mềm, những người sử dụng thông tin đầu ra của phần mềm. Gerhard đại diện cho kiểu khách hàng thanh toán, mua sắm hoặc tài trợ một dự án phần mềm. Các khách hàng mức cao nhưGerhard chịu trách nhiệm đặc tả các yêu cầu kinh doanh (business requirements). Họ cung cấp các ý tưởng ở mức cao về sản phẩm và lý do, sự hợp lý để khởi động dự án sản xuất sản phẩm đó. (Theo kinh nghiệm của tôi, đây là loại khách hàng quan trọng nhất, họ quyết định lý do về mặt kinh doanh tại sao lại có dự án này và đó cũng là lý do tại sao lại phải tiêu tốn cho dự án này. Một thay đổi quyết định của họ sau này có thể làm ngưng lại cả một dự án đang tiến hành, dù tiền chưa được chuyển vào tài khoản của nhà phát triển phần mềm – ND). Nhưthảo luận trong Chương 6, các yêu cầu kinh doanh (business requirements) mô tả mục tiêu (objectives) mà khách hàng, doanh nghiệp, hoặc những người liên quan khác mong muốn đạt được, hoặc các giá trị mà họ muốn nhận được từ hệ thống. Business requirements tạo ra định hướng cho dự án. Sau đó thì bất cứ cái gì được đặc tả nhưmột yêu cầu đều cần nhất quán với các business requirements, cũng phải nhất quán nhưvậy đối với các tính năng của phần mềm. Tuy nhiên, business requirements không cung cấp các chi tiết đủ để các nhà phát triển biết cái họ cần làm là gì (what to build). Mức yêu cầu tiếp theo – user requirements - cần được thu thập từ những người sẽ trực tiếp sử dụng hệ thống. Những người dùng đó (thường được gọi là người dùng Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 32
33. cuối – end users) là một kiểu khách hàng khác của hệ thống. Họ có thể mô tả cả các tác vụ (tasks) mà họ cần để thực thi với sự giúp đỡ của hệ thống và các đặc tính phi chức năng quan trọng để hệ thống có thể được chấp nhận. Trong số các kiểu khách hàng thì: Các khách hàng là người trả tiền cung cấp các thông tin về lý do cần xây dựng hệ thống, hợp đồng, hoặc phát triển ứng dụng tuỳ biến (custom application), tức là các business requirements. Các khách hàng là người ấn vào các phím máy tính hàng ngày để sử dụng hệ thống cung cấp các thông tin gọi là user requirements. Không may là cả hai kiểu khách hàng đều cảm thấy họ không có đủ thời gian để làm việc với các nhà phân tích yêu cầu, những người thu thập, phân tích và tài liệu hoá các yêu cầu. Đôi khi khách hàng kỳ vọng các nhà phân tích hoặc các nhà phát triển phác ra cái người dùng cần mà không phải mất nhiều thời gian để thảo luận và tài liệu hoá. Nếu chỉ thế thôi thì dễ. Nếu doanh nghiệp của bạn phụ thuộc nhiều vào sự thành công của việc ứng dụng một phần mềm nào đó thì bạn phải chấp nhận mất nhiều thời gian để làm việc với các nhà phân tích hệ thống. Tình trạng sẽ hơi khác đối với việc phát triển các phần mềm thương mại (các phần mềm đóng gói), khi đó khách hàng (customer) và người dùng (user) chỉ là một người. Các đại diện cho khách hàng, ví dụ bộ phận marketing của chính doanh nghiệp của bạn, sẽ phải cố gắng xác định cái gì khiến cho những người thanh toán tiền cảm thấy thích thú từ sản phẩm phần mềm doanh nghiệp bạn làm ra. Thậm chí đối với các phần mềm thương mại, chính bạn phải trở thành người dùng và Chương 7 sẽ nói chi tiết về việc này, nếu không thì bạn hãy chuẩn bị tinh thần đọc những đánh giá trên các tạp chí chuyên ngành về các hạn chế của phần mềm của bạn. II. SỰ CỘNG TÁC KHÁCH HÀNG – NHÀ PHÁT TRIỂN (THE CUSTOMER – DEVELOPER PARTNERSHIP) Các sản phẩm phần mềm chất lượng cao thường là kết quả của các thiết kế được thực thi tốt trên cơsở các yêu cầu tuyệt hảo. Các yêu cầu nhưvậy là kết quả của việc cộng tác và truyền thông tốt giữa nhà phát triển và khách hàng. Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 33
34. Dự luật Yêu cầu về Quyền của Khách hàng Phần mềm (Requirements Bill of Rights for Software Customers) liệt kê ra 10 kỳ vọng của khách hàng đối với nhà phân tích và nhà phát triển trong các hoạt động của quy trình yêu cầu. Mỗi trong số các quyền đó ngụ ý một trách nhiệm tương ứng về phía nhà phát triển và nhà phân tích. Dự luật Yêu cầu về Trách nhiệm của Khách hàng Phần mềm (Requirements Bill of Responsibilities for Software Customers) liệt kê ra 10 trách nhiệm của khách hàng đối với nhà phát triển trong quy trình yêu cầu. Nếu bạn thích, bạn có thể gọi đó là dự luật về quyền của nhà phát triển. DỰ LUẬT YÊU CẦU VỀ QUYỀN CỦA KHÁCH HÀNG PHẦN MỀM Nếu bạn là Khách hàng Phần mềm thì bạn có quyền: 1. Kỳ vọng nhà phân tích nói bằng ngôn ngữ của bạn. 2. Kỳ vọng nhà phân tích nắm được nghiệp vụ kinh doanh và mục tiêu mà bạn đặt ra cho hệ thống. 3. Kỳ vọng nhà phân tích cấu trúc hoá được thông tin mà bạn cung cấp thành một bản đặc tả yêu cầu phần mềm thành văn. 4. Đề nghị nhà phát triển diễn giải cho bạn tất cả các bán thành phẩm được tạo ra trong quy trình yêu cầu. 5. Kỳ vọng nhà phát triển có thái độ tôn trọng và duy trì sự hợp tác với bạn trong suốt quá trình làm việc chung. 6. Đề nghị nhà phát triển cung cấp cho bạn tất cả các ý tưởng và các lựa chọn mà anh ta có thể có về yêu cầu và sự thi công hệ thống từ các yêu cầu đó. 7. Mô tả các đặc tính của sản phẩm khiến cho nó dễ sử dụng và thân thiện hơn với người dùng. 8. Có cơhội điều chỉnh các yêu cầu nhằm có thể sử dụng lại các software components mà bạn đã có. 9. Có được các ước lượng tương đối tốt về chi phí, ảnh hưởng và các đánh đổi (trade-offs) khi bạn đề nghị một thay đổi trong số các yêu cầu. 10.Nhận được một hệ thống đáp ứng các nhu cầu của bạn về chức năng và chất lượng, đáp ứng sự mở rộng các nhu cầu đã được trao đổi và thoả thuận với nhà phát triển. Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 34
35. DỰ LUẬT YÊU CẦU VỀ TRÁCH NHIỆM CỦA KHÁCH HÀNG PHẦN MỀM Nếu bạn là Khách hàng Phần mềm thì bạn có trách nhiệm: 1. Giúp nhà phân tích hiểu về nghiệp vụ kinh doanh của bạn và định nghĩa các biệt ngữ nghiệp vụ (business jargon) cho họ hiểu. 2. Sẵn sàng tiêu tốn thời gian để cung cấp yêu cầu, làm sáng tỏ chúng và bổ sung chúng thường xuyên. 3. Cụ thể và chính xác khi cung cấp nguồn gốc của yêu cầu. 4. Ra quyết định đúng lúc về các công việc liên quan đến yêu cầu khi có đề nghị. 5. Tôn trọng sự đánh giá của nhà phát triển về chi phí và tính khả thi của yêu cầu. 6. Thiết lập ưu tiên cho các yêu cầu riêng lẻ, các tính năng hệ thống hoặc các tình huống sử dụng (use cases). 7. Soát xét các tài liệu yêu cầu và các nguyên mẫu (prototypes). 8. Truyền thông cho các bên liên quan về các thay đổi của yêu cầu ngay khi bạn biết được các thay đổi đó. 9. Tuân thủ quy trình đã được định nghĩa của công ty phát triển sản phẩm khi đề xuất các thay đổi yêu cầu. 10.Tôn trọng các quy trình mà nhà phát triển sử dụng cho công nghệ yêu cầu. Các quyền và trách nhiệm trên được áp dụng trực tiếp đối với khách hàng trong các hợp đồng làm phần mềm đặt hàng riêng, với các phần mềm loại này, công ty sản xuất phần mềm đã biết chính xác khách hàng là ai. Còn trường hợp phát triển các sản phẩm cho thị trường đại chúng (mass market) thì quyền và trách nhiệm được áp dụng cho các đại diện của khách hàng nhưbộ phận marketing chẳng hạn. Khi lập kế hoạch dự án, khách hàng và nhà phát triển cần phải soát xét kỹ 2 danh sách này để định ra một quy tắc làm việc chung. Các khách hàng bận rộn có thể không thích bị cuốn vào quy trình công nghệ yêu cầu (nhưquy định của Trách nhiệm 2). Thiếu sự tham gia của khách hàng nhất định sẽ tăng nguy cơsản xuất một sản phẩm sai. Hãy đảm bảo rằng tất cả những thành viên chính trong quy trình công nghệ yêu cầu đều hiểu và chấp nhận trách nhiệm của họ. Nếu phải đối mặt với một số điểm gây căng thẳng thì hãy đàm phán để đi đến hiểu biết chung. Sự Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 35
36. hiểu biết chung này sẽ giảm các xích mích không đáng có khi một bên kỳ vọng vào một cái gì đó mà bên kia không mong muốn hoặc không thể đáp ứng. Sau đây chúng ta sẽ xem xét kỹ hai dự luật trên. 1. DỰ LUẬT YÊU CẦU VỀ QUYỀN CỦA KHÁCH HÀNG PHẦN MỀM Quyền 1: Kỳ vọng nhà phân tích nói bằng ngôn ngữ của bạn Các thảo luận về yêu cầu cần tập trung vào các nghiệp vụ kinh doanh và các tác vụ của người dùng, trong khi thảo luận thì phải sử dụng từ vựng của chuyên ngành của bạn, bạn cần truyền đạt đến nhà phát triển đề nghị này. Bạn không cần phải hiểu về các biệt ngữ công nghệ thông tin khi trao đổi với nhà phân tích. Quyền 2: Kỳ vọng nhà phân tích nắm được nghiệp vụ kinh doanh và mục tiêu mà bạn đặt ra cho hệ thống Bằng cách tương tác, trao đổi với người dùng khi suy luận yêu cầu, nhà phân tích có thể hiểu tốt hơn nghiệp vụ của bạn và biết cách làm thế nào để làm ra sản phẩm thích hợp với bạn, đáp ứng tốt nhu cầu và sự kỳ vọng của bạn. Để giúp các nhà phát triển nắm vững nghiệp vụ của bạn, hãy mời họ đến quan sát những gì bạn và các đồng nghiệp của mình làm. Nếu hệ thống được xây dựng để thay thế ứng dụng đã có thì nhà phát triển phải sử dụng hệ thống hiện có nhưbạn đã sử dụng nó, điều đó giúp họ rút ra các kết luận bổ ích. Quyền 3: Kỳ vọng nhà phân tích cấu trúc hoá được thông tin mà bạn cung cấp thành một bản đặc tả yêu cầu phần mềm thành văn Nhà phân tích sẽ sắp xếp tất cả thông tin bạn và các khách hàng khác cung cấp nhằm phân loại nhu cầu người dùng thành các business requirements và các quy tắc (rules), các functional requirements, các mục tiêu chất lượng, các ý tưởng giải pháp và các thông tin khác. Sản phẩm cuối từ sự phân tích này là một đặc tả yêu cầu phần mềm (Software Requirement Specification, SRS). SRS cấu thành trên thoả thuận giữa nhà phát triển và khách hàng về nội dung của sản phẩm sẽ được xây dựng. SRS cần phải được cấu trúc và viết ra dưới dạng mà bạn có thể dễ dàng đọc và hiểu. Bạn có thể soát xét các đặc tả thành văn đó để đảm bảo chắc chắn rằng nó biểu diễn chính xác và đầy đủ các yêu cầu của bạn. Một SRS chất lượng cao thúc đẩy mạnh mẽ cơhội xây dựng sản phẩm bạn thực sự muốn. Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 36
37. Quyền 4: Đề nghị nhà phát triển diễn giải cho bạn tất cả các bán thành phẩm được tạo ra trong quy trình yêu cầu Nhà phân tích cần phải biểu diễn các yêu cầu bằng cách sử dụng nhiều sơđồ khác nhau nhằm làm sáng tỏ hơn SRS. Các sơđồ đó thật sự có giá trị trong việc biểu diễn một số hành vi của hệ thống, ví dụ các luồng công việc (workflows). Có thể bạn không quen thuộc lắm với các sơđồ nhưng bạn cũng không khó khăn lắm để hiểu nó. Bạn có thể đề nghị nhà phân tích giải thích mục đích của mỗi sơđồ hoặc các bán thành phẩm (work products) khác dẫn xuất từ yêu cầu, ý nghĩa của các ký hiệu (notation) và làm thế nào để kiểm tra các sơđồ nhằm tìm kiếm và loại bỏ lỗi và sự thiếu nhất quán. Quyền 5: Kỳ vọng nhà phát triển có thái độ tôn trọng và duy trì sự hợp tác với bạn trong suốt quá trình làm việc chung Các thảo luận về yêu cầu có thể được làm tốt dần nếu người dùng và nhà phát triển chưa nắm bắt được các yêu cầu ngay từ đầu. Làm việc nhóm cùng nhau sẽ khiến cả khách hàng và nhà phát triển đều hiểu vấn đề sâu hơn. Quyền 6: Đề nghị nhà phát triển cung cấp cho bạn tất cả các ý tưởng và các lựa chọn mà anh ta có thể có về yêu cầu và sự thi công hệ thống từ các yêu cầu đó Thông thường khách hàng đề xuất các ý tưởng về “yêu cầu” (“requirements” ideas) là các giải pháp có thể thực thi (possible implementation solutuions). Các nhà phân tích sẽ cố gắng tìm hiểu đằng sau các giải pháp đó để hiểu được các vấn đề nghiệp vụ thực sự và nhu cầu cần được chỉ mặt, đặt tên (nghĩa là cố gắng tìm hiểu mục đích nào mà khách hàng muốn đạt được sau khi thực hiện giải pháp đó - ND). Các nhà phân tích cần duyệt qua tất cả những gì mà hệthống hiện tại không đáp ứng được các quy trình kinh doanh hiện thời, nhằm đảm bảo rằng sản phẩm làm ra vượt qua được các nhược điểm đó. Nhà phân tích là người hiểu được lĩnh vực nghiệp vụ (business domain, thuật ngữ chỉ miền ứng dụng của sản phẩm phần mềm, ví dụ tài chính là một business domain - ND) và có thể đề xuất các cải tiến cần thiết, đồng thời anh ta cũng có thể thêm vào phần mềm mới các tính năng có giá trị mà người dùng cũng chưa mường tượng ra được. Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 37
38. Quyền 7: Mô tả các đặc tính của sản phẩm khiến cho nó dễ sử dụng và thân thiện hơn với người dùng Bạn có thể kỳ vọng các nhà phân tích hỏi bạn các đặc tính mà phần mềm cần có để nó dễ sử dụng hơn. Các đặc tính đó, hoặc các thuộc tính chất lượng, khiến cho phần mềm thân thiện hơn và giúp bạn hoàn thành các tác vụ (tasks) của mình chính xác và hiệu quả hơn. Ví dụ, khách hàng đôi khi hay nói rằng sản phẩm phải “thân thiện người dùng” (user-friendly) hoặc “ổn định” (robust), “hiệu quả “ (efficient), nhưng những yêu cầu nhưvậy không giúp gì nhiều cho nhà phát triển vì chúng khá cảm tính. Thay vì vậy, nhà phân tích cần cụ thể hoá thế nào thì được gọi là “thân thiện người dùng” hoặc “ổn định”, “hiệu quả “ đối với khách hàng (Chương 11). Quyền 8: Có cơhội điều chỉnh các yêu cầu nhằm có thể sử dụng lại các software components mà bạn đã có Yêu cầu thường cần một mức độ mềm dẻo nào đó. Nhà phân tích cần nhận thức được rằng các software components đang có đã đáp ứng một số nhu cầu hiện tại của bạn. Trong trường hợp đó, nhà phân tích cần đề xuất lựa chọn sửa đổi yêu cầu của bạn sao cho có thể sử dụng lại các components đã có trong hệ thống mới. Nếu bạn có thể điều chỉnh yêu cầu của mình sao cho nhu cầu vẫn được đáp ứng và sử dụng lại được các components đã có thì bạn sẽ tiết kiệm được nhiều thời gian và tiền bạc hơn. Một số yêu cầu phải khá mềm dẻo để bạn có thể sử dụng được các COTS components (là software components được các công ty phần mềm sản xuất sẵn và được thương mại hóa, ví dụ đối với lĩnh vực xây dựng thì gạch lát nền nhà là một dạng tương tự COST component - ND). Quyền 9: Có được các ước lượng tương đối tốt về chi phí, ảnh hưởng và các đánh đổi (trade-offs) khi bạn đề nghị một thay đổi trong số các yêu cầu Đôi khi người ta thực hiện các lựa chọn khác nhau khi chi phí giữa các lựa chọn là khác nhau. Cần có ước lượng về ảnh hưởng và chi phí của mỗi thay đổi được đề xuất đối với các yêu cầu để ra quyết định kinh doanh về các thay đổi này, nghĩa là nên lựa chọn thay đổi nào. Bạn có quyền kỳ vọng nhà phát triển đưa ra các ước lượng về ảnh hưởng, chi phí, và đánh đổi cho mỗi thay đổi. Nhà phát triển không được thổi phồng các chi phí được ước tính của một thay đổi vì lý do họ không muốn thực hiện sự thay đổi đó. Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 38
39. Quyền 10: Nhận được một hệ thống đáp ứng các nhu cầu của bạn về chức năng và chất lượng, đáp ứng sự mở rộng các nhu cầu đã được trao đổi và thoả thuận với nhà phát triển Bất cứ ai cũng mong muốn kết quả này cho dự án. Kết quả này chỉ có thể hiện thực nếu nhà phát triển được biết tất cả thông tin về các lựa chọn và ràng buộc cho phép họ làm ra sản phẩm đáp ứng tốt nhu cầu của bạn. 2. DỰ LUẬT YÊU CẦU VỀ TRÁCH NHIỆM CỦA KHÁCH HÀNG PHẦN MỀM Trách nhiệm 1: Giúp nhà phân tích hiểu về nghiệp vụ kinh doanh của bạn và định nghĩa các biệt ngữ nghiệp vụ cho họ hiểu Nhà phân tích kỳ vọng bạn đào tạo cho anh ta vềnghiệp vụ kinh doanh và các thuật ngữ bạn dùng. Việc này không hề giúp anh ta trở thành chuyên gia trong lĩnh vực của bạn, nó chỉ giúp anh ta hiểu được những gì bạn nói, hiểu được mục tiêu của bạn. Đừng kỳ vọng nhà phân tích có thể nắm bắt sâu sắc các khía cạnh đa dạng trong nghiệp vụ của bạn. Trách nhiệm 2: Sẵn sàng tiêu tốn thời gian để cung cấp yêu cầu, làm sáng tỏ chúng và bổ sung chúng thường xuyên Khách hàng là những người bận rộn và thường những ai liên quan nhiều nhất đến quy trình yêu cầu lại là người bận rộn nhất. Bạn hãy cố gắng dành thời gian tham gia các hội thảo, các phiên họp tập kích não (brainstorming), các buổi phỏng vấn, các hoạt động khác liên quan đến yêu cầu. Đôi khi nhà phân tích cho rằng anh ta hiểu một điểm nào đó trong số các công việc của bạn nhưng chỉ khi triển khai sâu hơn công việc thì anh ta lại có nhu cầu làm sáng sủa vấn đề hơn. Hãy kiên nhẫn với cách tiếp cận lặp trong việc phát triển và định nghĩa yêu cầu, cũng vì bản chất của việc trao đổi thông tin qua lại giữa bạn và nhà phân tích là phức tạp, và vì sự thành công của dự án là quan trọng nhất. Trách nhiệm 3: Cụ thể và chính xác khi cung cấp nguồn gốc của yêu cầu Trình bày rõ, chính xác các yêu cầu là việc khó khăn, vì vậy bất cứ lúc nào nhà phân tích cũng cần gặp ai đó trong số khách hàng để được giúp đỡ phân giải các yêu cầu nhập nhằng và thiếu chính xác. Nên tạm đánh dấu TBD (cần được xác định – to be determined) trên một yêu cầu nào đó trong bản đặc tả yêu cầu, nghĩa là Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 39
40. ta cần các nghiên cứu, phân tích bổ sung, thêm các thông tin cần thiết đối với yêu cầu đó – yêu cầu chưa được hiểu rõ tại thời điểm ấy. Đôi khi, TBD được sử dụng trên một yêu cầu nào đó vì nó đã được xác định là rất khó khăn để giải quyết và không ai muốn tiếp tục xử lý nó nữa. Trách nhiệm 4: Ra quyết định đúng lúc về các công việc liên quan đến yêu cầu khi có đề nghị Khi nhà phân tích phân giải yêu cầu thì anh ta phải đối mặt với nhiều lựa chọn và quyết định (choices and decisions), anh ta chỉ được chọn một với một chi phí tương ứng. Mỗi quyết định bao gồm phân giải các đề nghị thiếu nhất quán từ nhiều người dùng, thực hiện các đánh đổi giữa các thuộc tính chất lượng xung đột nhau, đánh giá sự chính xác của thông tin. Khách hàng chính là người ra quyết định tại mỗi thời điểm cần sự lựa chọn đó. Nhà phân tích thường phải chờ đợi quyết định của bạn tại mỗi thời điểm nhưvậy, tiến độ của dự án phụ thuộc một phần vào việc ra quyết định của bạn. Trách nhiệm 5: Tôn trọng sự đánh giá của các nhà phát triển về chi phí và tính khả thi của yêu cầu Tất cả chức năng của phần mềm đều có giá (price) và nhà phát triển là người ước lượng tốt nhất chi phí xây dựng chức năng đó (mặc dầu nhiều nhà phát triển không phải là một người ước lượng có kỹ năng). Một số tính năng mà bạn muốn thêm vào sản phẩm nhưng việc đó không khả thi về mặt kỹthuật hoặc quá đắt để thực thi. Một số yêu cầu là phi thực tế trong điều kiện hiện tại của doanh nghiệp của bạn. Nhà phát triển có thể là kẻ đưa tin xấu về tính khả thi hoặc chi phí của một yêu cầu nào đó, nhưng bạn nên tôn trọng lời nói của anh ta. Đôi khi bạn có thể viết lại các yêu cầu theo một cách khiến chúng khả thi hoặc rẻ hơn đểthực hiện. Ví dụ, yêu cầu “hệ thống phản ứng ngay lập tức” không khả thi nhưng nếu bạn viết yêu cầu “hệ thống phản ứng trong vòng 50 mili giây” thì lại khảthi. Trách nhiệm 6: Thiết lập ưu tiên cho các yêu cầu riêng lẻ, các tính năng hệ thống hoặc các tình huống sử dụng (use cases) Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 40
41. Phần lớn các dự án không có thời gian hoặc tài nguyên để thực thi tất cả các yêu cầu cùng một lúc. Hãy xác định tính năng nào là quan trọng, cơbản để xác định thứ tự ưu tiên trong việc xây dựng hệ thống. Bạn chính là người đưa ra thứ tự ưu tiên này vì nhà phát triển không thể làm điều đó từ góc độ của anh ta được. Nhà phát triển sẽ cung cấp thông tin chi phí và rủi ro của mỗi yêu cầu nhằm giúp bạn định nghĩa thứ tự này. Khi bạn đã thiết lập thứ tự ưu tiên này, bạn đã đảm bảo nhà phát triển chuyển giao cho bạn sản phẩm với giá trị lớn nhất, chi phí thấp nhất và tại thời điểm hợp lý nhất. Thứ tự ưu tiên này giúp bạn dễ co giãn được phạm vi dự án tại từng thời điểm nhất định căn cứ trên nhu cầu thực tế của doanh nghiệp, trên thời gian và ngân sách của doanh nghiệp. Trách nhiệm 7: Soát xét các tài liệu yêu cầu và các nguyên mẫu (prototypes) Nhưbạn sẽ thấy trong Chương 14, hoạt động soát xét (reviews) tài liệu yêu cầu là một trong số các hoạt động có giá trị nhất ảnh hưởng đến chất lượng phần mềm. Khách hàng cần tham gia vào hoạt động này vì đó là cách duy nhất để đánh giá liệu bản mô tả yêu cầu đã xác định các đặc tính của phần mềm một cách đầy đủ, đúng đắn và cần thiết hay chưa. Mỗi phiên soát xét sẽ là một cơhội cho các đại diện của khách hàng phản hồi cho các nhà phân tích về công việc của họ, liệu họ đã đáp ứng đúng nhu cầu dự án chưa. Nếu bạn không tin tài liệu yêu cầu là chính xác, hãy nói với người có trách nhiệm càng sớm càng tốt và đưa ra các đề nghị cải tiến. Rất khó khăn để có thể phác ra một bức tranh sống động về hoạt động của phần mềm chỉ bằng cách đọc một đặc tả yêu cầu. Để hiểu tốt hơn nhu cầu của bạn và đề xuất những cách tốt nhất để đáp ứng các nhu cầu đó, nhà phát triển thường xây dựng các nguyên mẫu (tương tự bây giờ khi bán căn hộ chung cưcho khách hàng, công ty xây dựng cho khách hàng xem căn hộ mẫu trước - ND) cho sản phẩm mong muốn. Phản hồi của bạn về nguyên mẫu sẽ cung cấp các thông tin rất giá trị cho nhà phát triển và giúp họ hiểu tốt hơn yêu cầu. Nguyên mẫu không phải là một sản phẩm thực sự và nhà phát triển cũng không biến đổi nguyên mẫu thành hệ thống đầy đủ được. Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 41
42. Trách nhiệm 8: Truyền thông cho các bên liên quan các thay đổi về yêu cầu ngay khi bạn biết được các thay đổi đó Sự thay đổi liên tục của yêu cầu gây ra rủi ro nghiêm trọng đối với nhà phát triển trong việc chuyển giao một sản phẩm chất lượng cao cho khách hàng với một lịch biểu đã định. Thay đổi là không thể tránh khỏi, nhưng càng về cuối chu trình phát triển thì một thay đổi càng ảnh hưởng nhiều, chúng khiến nhiều công việc phải làm lại và chi phí phát sinh là rất lớn. Vậy hãy thông báo cho nhà phát triển ngay khi bạn thấy cần thay đổi yêu cầu, thông báo càng sớm càng tốt. Trách nhiệm 9: Tuân thủ quy trình đã được định nghĩa của công ty phát triển sản phẩm khi đề xuất các thay đổi yêu cầu Để tối thiểu hoá các ảnh hưởng tiêu cực của thay đổi, tất cả những người tham gia dự án đều phải tuân theo quy trình kiểm soát thay đổi đã được định nghĩa của dự án. Điều này đảm bảo các thay đổi đề xuất không bị mất tích, các ảnh hưởng của thay đổi được phân tích đầy đủ và được cân nhắc theo một cách nhất quán. (Trong các dự án phần mềm, các thay đổi yêu cầu rất hay bị mất tích, tuần trước rõ ràng đã sửa chức năng đó theo yêu cầu được thay đổi rồi nhưng tuần sau cập nhật phiên bản mới lại thấy chức năng đó vẫn nhưcũ, chưa hề được sửa –ND). Trách nhiệm 10: Tôn trọng các quy trình mà nhà phát triển sử dụng cho công nghệ yêu cầu Thu thập yêu cầu và đảm bảo chúng đúng đắn là thách thức lớn nhất của phát triển phần mềm. Có một sự hợp lý ẩn đằng sau cách tiếp cận xây dựng yêu cầu của nhà phân tích. Mặc dù bạn vẫn có thể bổ sung và làm mịn các yêu cầu trong giai đoạn sau nhưng thời gian tiêu tốn cho giai đoạn phát triển yêu cầu thật sự là một khoản đầu tưhữu ích. Quy trình thu thập yêu cầu sẽ bớt chông gai hơn nếu bạn hiểu và tôn trọng các kỹ thuật nhà phân tích dùng để thu thập, tài liệu hoá và đảm bảo chất lượng yêu cầu. Hãy cứ đề nghị nhà phân tích diễn giải cặn kẽ cho bạn tất cả những gì bạn chưa rõ trong quy trình yêu cầu đó. III. DẤU HIỆU DỪNG LẠI LÀ GÌ? (WHAT ABOUT SIGH-OFF?) Đạt được thoả thuận về yêu cầu là một phần quan trọng trong sự cộng tác giữa khách hàng – nhà phát triển. Nhiều tổ chức sử dụng khái niệm “signing off” để chỉ việc khách hàng chấp nhận và thông qua văn bản yêu cầu. Điều quan trọng là tất cả Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 42
43. những người tham gia quy trình chấp thuận yêu cầu (requirements approval process) phải biết chính xác sign-off nghĩa là gì. Quá trình thu thập và phân tích yêu cầu tạm thời dừng lại khi nhà phát triển và khách hàng thống nhất được một ranh giới (baseline) của bản đặc tả yêu cầu. Khi ký xác nhận ranh giới đó thì bạn cần thêm vào SRS đoạn văn sau: “Tôi xác nhận rằng tài liệu mô tả yêu cầu này là hiểu biết tốt nhất của chúng tôi về các yêu cầu phần mềm cho dự án tính đến ngày hôm nay. Các thay đổi tương lai đối với ranh giới này sẽ được thực hiện thông qua quy trình thay đổi đã được định nghĩa của dự án. Tôi nhận thức rằng các thay đổi đã được chấp thuận này có thể vẫn khiến chúng tôi đàm phán lại các cam kết về chi phí, nguồn lực, lịch biểu của dự án.” Các bước tiếp theo Xác định các khách hàng cá nhân có trách nhiệm cung cấp business requirements và user requirements trong dự án của bạn. Mỗi mục nào trong trong Bill of Rights và Bill of Responsibilities đã được chấp thuận, được hiểu, được thực hiện bởi các khách hàng đó? Mục nào không? Hãy thảo luận về Bill of Rights và Bill of Responsibilities với các khách hàng chính để đạt được sự thoả thuận trách nhiệm nào sẽ được chấp thuận và họ cảm thấy gì khi không nhận được một quyền nào đó. Dựa vào đó hãy đề ra các biện pháp cải thiện tốt hơn quan hệ cộng tác Khách hàng – Nhà phát triển. Nếu bạn là một khách hàng tham gia vào một dự án phần mềm và bạn không cảm thấy các quyền của bạn được tôn trọng thì hãy thảo luận về Bill of Rights với các nhà phát triển. Hãy xác nhận trách nhiệm của mình trong Bill of Responsibilities để từ đó đề nghị họ thực hiện trách nhiệm của họ. Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 43
44. CHƯƠNG 3 GOOD PRACTICES CHO CÔNG NGHỆ YÊU CẦU Mười năm trước đây, tôi rất hâm mộ các phương pháp luận phát triển phần mềm - tập hợp các mô hình và kỹ thuật nhằm giúp tôi giải quyết các thách thức của dự án phần mềm. Ngày nay, tôi quan tâm hơn đến việc xác định và ứng dụng cái được gọi là “best practices”. Thuật ngữ “best practices”, mặc dù còn gây nhiều tranh cãi, nhưng nó có ý nghĩa là: anh nhận được một lời khuyên gọi là “best” và làm theo lời khuyên đó anh đạt được kết quả tốt nhất cho công việc của mình. Cách tiếp cận này là sự tổng kết thành công và thất bại của các chuyên gia trong rất nhiều dự án ở rất nhiều tổ chức khác nhau (Brown 1996). Từ đó họ rút ra được các yếu tố chung, tổng quát mang lại thành công cho nhiều dự án khác nhau, các yếu tố đó gọi là “best practices” (hướng dẫn thực hành tốt nhất). Tuy nhiên, đầu đề của chương này là “Good practices cho công nghệ yêu cầu” chứ không phải “best practices”. Chương này sẽ trình bày hơn 40 practices trong 7 nhóm khác nhau. Bảng 3-1: GOOD PRACTICES CHO CÔNG NGHỆ YÊU CẦU Tri thức Quản lý yêu cầu Quản lý dự án (Knowledge) (Requirements (Project Management) Management) Đào tạo các nhà Định nghĩa quy trình Lựa chọn một vòng phân tích yêu cầu kiểm soát thay đổi đời thích hợp (Select (Train requirements (Define change control appropriate life cycle) analysis) process) Lập kế hoạch dự án Giáo dục cho đại Thành lập ban kiểm soát dựa trên yêu cầu diện người dùng và thay đổi (Establish (Base plans on các nhà quản lý về change control board) requirements) yêu cầu (Educate Thực hiện các phân tích Đàm phán nhiều lần user reps and về ảnh hưởng của thay về các cam kết managers about đổi (Perform change (Renegotiate requirements) impact analysis) commitments) Đào tạo các nhà Lần vết mỗi thay đổi đối Quản lý rủi ro của yêu phát triển trong với tất cả các bán thành cầu (manage Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 44
45. miền ứng dụng phẩm bị ảnh hưởng requirements risks) (Train developers in (Trace each change to Giám sát nhân lực application domain) all affected work thực hiện yêu cầu Tạo ra một bảng products) (Track requirements thuật ngữ (Create a Vạch ranh giới và kiểm effort) glossary) soát các phiên bản của tài liệu yêu cầu (Baseline and control versions of requirements documents) Duy trì lịch sử thay đổi (Maintain change history) Giám sát tình trạng yêu cầu (Track requirements status) Đo lường sự ổn định của yêu cầu (Measure requirements stability) Sử dụng một công cụ quản lý yêu cầu (Use a requirements management tool) Bảng 3-1: GOOD PRACTICES CHO CÔNG NGHỆ YÊU CẦU (Tiếp) Phát triển yêu cầu (Requirements Development) Suy luận Phân tích Đặc tả Kiểm tra (Elicitation) (Analysis) (Specification) (Verification) Viết tầm nhìn Vẽ sơ đồ bối Thông qua Thanh tra tài và phạm vi cảnh của bài mẫu SRS liệu yêu cầu (Write vision toán (Draw (Adopt SRS (Inspect and scope) context template) requirements Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 45
46. Định nghĩa thủ diagram) Xác định document) tục phát triển Tạo ra các nguồn gốc Viết các test yêu cầu (Define nguyên mẫu yêu cầu cases từ các yêu requirements (Create (Identify cầu (Write test development prototypes) sources of cases from procedure) Phân tích tính requirements) requirements) Xác định các khả thi Gán nhãn Viết tài liệu lớp người dùng (Analyze mỗi yêu cầu hướng dẫn (Identify user feasibility) (Label each người dùng classes) Xếp thứ tự ưu requirement) (Write a user Lựa chọn sự trợ tiên các yêu cầu Ghi lại các manual) giúp sản phẩm (Prioritize quy tắc Định nghĩa tiêu (Select product requirements) nghiệp vụ chuẩn chấp champions) Mô hình hoá (Record nhận (Define Thành lập các yêu cầu business acceptance nhóm tập trung (Model the rules) criteria) (Establish focus requirements) Tạo ra ma groups) Tạo một từ điển trận có thể Xác định các dữ liệu (Create lần vết yêu use cases a data cầu (Create (Identify use dictionary) requirements cases) Ứng dụng traceability Tổ chức các Quality matrix) phiên JAD Function (Hold JAD Deployment sessions) (Apply Quality Phân tích luồng Function công việc người Deployment) dùng (Analyze user workflows) Định nghĩa các thuộc tính chất Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 46
47. lượng (Define quality attributes) Kiểm tra các báo cáo vấn đề (Examine problem reports) Sử dụng lại yêu cầu (Reuse requirements) Không phải tất cả các mục trên đều được tán thành là các best practices trong công nghiệp phần mềm (industry best practices). Tôi không cho rằng tất cả các mục đó đều được đánh giá một cách hệ thống vì mục đích này. Tuy nhiên, tôi và nhiều đồng nghiệp khác đã thấy các kỹ thuật này hiệu quả (Sommerville and Sawyer 1997). Mỗi practice sẽ được mô tả ngắn gọn và chỉ ra chương nói về nó trong cuốn sách này hoặc các nguồn tham khảo khác. Bảng 3-2 nhóm các practices đó theo một thứ tự ưu tiên tương đối khi thi công dự án và độ khó tương đối khi ứng dụng các practices đó. Khi tất cả các practices đó phát huy tác dụng thì bạn có thể gặt hái kết quả - xác suất sự thành công của dự án sẽ lớn hơn. Bảng 3-2: THỰC THI CÔNG NGHỆ YÊU CẦU (IMPLEMENTING REQUIREMENTS ENGINEERING) Good Practices Ưu tiên Độ khó (Difficulty) (Priority) High Medium Low High Định nghĩa thủ Xác định các use Đào tạo các nhà phát tục phát triển cases (Identify use triển trong miền ứng yêu cầu (Define cases) dụng (Train requirements Định nghĩa các developers in Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 47
48. development thuộc tính chất application domain) procedure) lượng (Define Viết tầm nhìn và Lập kế hoạch quality attributes) phạm vi (Write dự án dựa trên Xếp thứ tự ưu tiên vision and scope) yêu cầu (Base các yêu cầu Xác định các lớp plans on (Prioritize người dùng requirements) requirements) (Identify user Đàm phán Thông qua mẫu classes) nhiều lần về các SRS (Adopt SRS Vẽ sơđồ bối cảnh cam kết template) của bài toán (Draw (Renegotiate Định nghĩa quy context diagram) commitments) trình kiểm soát Xác định nguồn gốc thay đổi (Define yêu cầu (Identify change control sources of process) requirements) Thành lập ban Gán nhãn mỗi yêu kiểm soát thay đổi cầu (Label each (Establish change requirement) control board) Vạch ranh giới và Thanh tra tài liệu kiểm soát các phiên yêu cầu (Inspect bản của tài liệu yêu requirements cầu (Baseline and document) control versions of requirements documents) Medium Giáo dục cho Đào tạo các nhà Tạo ra một bảng đại diện người phân tích yêu cầu thuật ngữ (Create a dùng và các nhà (Train requirements glossary) quản lý về yêu analysis) Lựa chọn sự trợ giúp cầu (Educate Thành lập nhóm tập sản phẩm (Select user reps and trung (Establish product champions) managers about focus groups) Tạo một từ điển dữ requirements) Tạo ra các nguyên liệu (Create a data Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 48
49. Mô hình hoá mẫu (Create dictionary) các yêu cầu prototypes) Ghi lại các quy tắc (Model the Phân tích tính khả nghiệp vụ (Record requirements) thi (Analyze business rules) Quản lý rủi ro feasibility) Viết các test cases từ của yêu cầu Định nghĩa tiêu các yêu cầu (Write (manage chuẩn chấp nhận test cases from requirements (Define acceptance requirements) risks) criteria) Giám sát tình trạng Sử dụng một Thực hiện các phân yêu cầu (Track công cụ quản lý tích về ảnh hưởng requirements status) yêu cầu (Use a của thay đổi requirements (Perform change management impact analysis) tool) Lần vết mỗi thay Tạo ra ma trận đổi đối với tất cả có thể lần vết các bán thành phẩm yêu cầu (Create bị ảnh hưởng (Trace requirements each change to all traceability affected work matrix) products) Lựa chọn một vòng đời thích hợp (Select appropriate life cycle) Low Tổ chức các Phân tích luồng phiên JAD công việc người (Hold JAD dùng (Analyze user sessions) workflows) Sử dụng lại yêu Kiểm tra các báo cầu (Reuse cáo vấn đề requirements) (Examine problem Ứng dụng reports) Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 49
50. Quality Viết tài liệu hướng Function dẫn người dùng Deployment (Write a user (Apply Quality manual) Function Duy trì lịch sử thay Deployment) đổi (Maintain Đo lường sự ổn change history) định của yêu Giám sát nhân lực cầu (Measure thực hiện yêu cầu requirements (Track requirements stability) effort) Đừng cố gắng ứng dụng tất cả các kỹ thuật trên vào dự án sắp tới của bạn. Thay vì vậy, hãy suy nghĩ về các good practices đã mô tả ở đây nhưlà các mục mới để thêm vào requirements tool kit của bạn. Bạn có thể bắt đầu bằng cách ứng dụng ngay một số practices, ví dụ các practices về quản trị thay đổi mà không cần quan tâm gì đến việc dự án của bạn tiến hành đến đâu. Chương 4 giới thiệu các cách tiếp cận bạn có thể sử dụng để đánh giá các practices bạn đang dùng trong dự án hiện tại liên quan đến công nghệ yêu cầu và sáng tạo ra một lộ trình (road map) để thực hiện cải tiến quy trình yêu cầu được lựa chọn ra từ các practices ở đây (Chương 3) và ở Chương 4. I. TRI THỨC (KNOWLEDGE) Chỉ một số ít nhà phát triển phần mềm được đào tạo một cách chính thức các kỹ năng và kỹ thuật cần thiết cho công nghệ yêu cầu. Tuy vậy, trên thực tế một số nhà phát triển vẫn phải đóng vai trò phân tích viên yêu cầu khi phải làm việc với khách hàng để thu thập, phân tích và tài liệu hoá yêu cầu. Một số khoá đào tạo có thể giúp các nhà phát triển bổ sung các kỹ năng còn thiếu này, giúp họ làm tốt vai trò phân tích viên yêu cầu. Do quy trình yêu cầu là một quy trình chủ chốt đối với sự thành công của dự án, nên tất cả những người liên quan đến dự án (stakeholders) cần phải có một hiểu biết cơbản về sự hợp lý, tầm quan trọng, các practices của công nghệ yêu cầu. Tổ Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 50
51. chức một khoá đào tạo ngắn trong 1 hoặc 2 ngày cho những người liên quan (nhà phát triển, người làm marketing, khách hàng, kiểm thử viên, các nhân viên quản lý) về quy trình yêu cầu khái quát có thể là một hoạt động xây dựng nhóm hiệu quả. Tất cả những người tham gia sẽ có một hiểu biết tốt hơn về những thách thức mà các đồng nghiệp của họ phải đối mặt, họ sẽ biết cách phối hợp tốt hơn với các đồng nghiệp vì sự thành công của dự án. Tương tự, các nhà phát triển sẽ có được các khái niệm và thuật ngữ của miền ứng dụng. Đào tạo các nhà phân tích yêu cầu (Train requirements analysts) Tất cả các nhà phát triển sẽ được đào tạo các kiến thức cơbản trong công nghệ yêu cầu, nhưng những người trong số họ chịu trách nhiệm chính về nắm bắt, tài liệu hoá, phân tích các yêu cầu người dùng cần được đào tạo kỹ hơn về các hoạt động này. Các nhà phân tích yêu cầu có kỹ năng được tập hợp lại, họ cần có kỹ năng giao tiếp tốt, hiểu biết miền ứng dụng và có thể lựa chọn các công cụ xử lý yêu cầu (tool kit) trợ giúp cho công việc của mình. Giáo dục đại diện người dùng và các nhà quản lý về yêu cầu phần mềm (Educate user representatives and managers about software requirements) Đại diện người dùng sẽ tham gia vào các hoạt động triển phần mềm, họ sẽ được giáo dục 1 ngày về công nghệ yêu cầu cùng các nhà quản lý bên phát triển và bên khách hàng. Họ sẽ hiểu được tầm quan trọng của yêu cầu, các hoạt động và các bán thành phẩm cần chuyển giao cho nhóm yêu cầu, các rủi ro xảy ra nếu sao nhãng quy trình yêu cầu. Đào tạo các nhà phát triển về các khái niệm của miền ứng dụng (Train developers in application domain concepts) Để giúp các nhà phát triển có được hiểu biết về miền ứng dụng, hãy thu xếp cho họ các khoá học ngắn về các hoạt động nghiệp vụ của khách hàng, về các thuật ngữ, các mục tiêu của sản phẩm cần được sản xuất. Việc này sẽ làm giảm sự hỗn độn, giảm sự rối loạn truyền thông (miscommunication) giữa các bên liên quan và giảm các công việc phải làm lại sau này. Bạn cũng có thể giải thích thêm với các nhà phát triển về các biệt ngữ và các khái niệm nghiệp vụ quan trọng trong diễn biến của dự án sau này. Người trợ giúp sản phẩm (product champion) sẽ đóng vai trò này. Cuốn sách này thuộc “Tủ sách Công nghệ thông tin”, tủ sách do SATA-APTECH tuyển chọn và giới thiệu. Bạn có thểxem và tải về trên www.sata-aptech.edu.vn , hoặc satablog2.wordpress.com 51