Software Requirements. First Edition – MS Press. Giới thiệu và Mục lục cuốn sách

SRcover

ĐÔI LỜI GIỚI THIỆU

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 quá, vả lại 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 khoảng 5 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 xuất bản. Cuốn này hiện đã có ấn bản mới cũng được Microsoft Press xuất bản, ấn bản mới có bản mềm, các bạn có thể tải về đọc. 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 sản xuất 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àngBướ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è. Đấy, 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.

Khi đọc sách tiếng Tây, tôi có thói quen ghi lại, tóm tắt hoặc chi tiết tùy từng cuốn, bằng tiếng Việt như là một cách để nắm được những gì đã đọc. Đây là một cuốn sách khá hay về quy trình làm yêu cầu phần mềm nên tôi đưa lên satablog2 dần dần để các bạn cùng tham khảo.

Hoàng Xuân Thịnh

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) 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 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 đáp ứng nhu cầu về chức năng và nhu cầu sử dụng của bản thân. 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 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 http://www.processimpact.com. 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 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 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ọ.

Mục lục

LỜI NÓI ĐẦU

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

23/09/2009

10 phản hồi

Filed under Quản lý yêu cầu phần mềm, Tủ sách Công nghệ thông tin

10 responses to “Software Requirements. First Edition – MS Press. Giới thiệu và Mục lục cuốn sách

  1. Phân tích và quản lý yêu cầu phần mềm

    Anh có thể dịch ra cuốn sách đó không ạh,em đang học môn này ,rất cần tài liệu!

  2. sata2009blog

    Chào em, anh đang dịch cuốn sách đó và sẽ đưa lên đây toàn bộ nội dung của nó, đó là cuốn sách khá hay và thiết thực trong số các cuốn sách cùng loại, tất nhiên là theo ý kiến của anh.

  3. Phân tích và quản lý yêu cầu phần mềm

    Hi vong anh có dịch nhanh nhanh chút ạh,em đang cần gấp,thanks,àh,anh co the cho em mail hoặc yahoo của anh được không ạh,vì có nhiều cái em chưa rõ lắm,muốn trao đổi trực tiếp với anh.

  4. sata2009blog

    Cam on em, em co the gui thu qua email trong muc Lien he em a.

  5. ban_mai

    Anh ơi,anh có thể phân tích dùm em cái này được hok,- Software process: nêu các đặc trưng, các key idea của các quy trình phát triển phần mềm cơ bản (qtrình xoắn ốc, thác nước, …),em tìm tài liệu mà hok có nói gì về nó hết!

  6. sata2009blog

    Chào em, những gì em muốn biết quá nhiều so với phạm vi một comment có thể nói :=) Những nội dung đó sẽ được bàn tới trong satablog2 sau này. Em cứ xem nhé. Cám ơn em.

  7. anh có link cuốn sách đó ko. tiếng ANh cũng đc.
    em rất thích nó.

  8. ban_mai

    Anh ơi,cho em hỏi khâu quan trọng nhất trong việc lấy yêu cầu là gì ạh,em xin cảm ơn anh!

  9. sata2009blog

    Chào ban_mai, anh sẽ trao đổi lại với em trong ít hôm nữa. Chúc vui!

  10. sata2009blog

    Xin chào ban_mai, anh trả lời câu hỏi của em. Theo ý anh, về mặt kỹ thuật – vì quy trình tức là chuỗi kỹ thuật thực thi một công việc, thì cũng có những khó khăn nhưng không phải không làm được khi lấy yêu cầu. Khâu quan trọng nhất trong việc lấy yêu cầu chính là thái độ của nhóm dự án đối với việc này, có thể nhóm cho rằng việc lấy yêu cầu không quan trọng, còn nếu họ cho rằng nó quan trọng thì có thể họ không cho rằng cần phải lấy yêu cầu theo một quy cách đã định chuẩn, việc loại bỏ những suy nghĩ này có lẽ là “khâu quan trọng nhất” em ạ. Chúc vui!

Gửi phản hồi

Mời bạn điền thông tin vào ô dưới đây hoặc kích vào một biểu tượng để đăng nhập:

WordPress.com Logo

Bạn đang bình luận bằng tài khoản WordPress.com Log Out / Thay đổi )

Twitter picture

Bạn đang bình luận bằng tài khoản Twitter Log Out / Thay đổi )

Facebook photo

Bạn đang bình luận bằng tài khoản Facebook Log Out / Thay đổi )

Google+ photo

Bạn đang bình luận bằng tài khoản Google+ Log Out / Thay đổi )

Connecting to %s