Category Archives: Tủ sách Công nghệ thông tin

Khái quát về tính toán đám mây

Đây là bản dịch Chương 1 cuốn sách “Handbook of Cloud Computing”, Springer xuất bản năm 2010. Cuốn sách được tổ chức sao cho mỗi chương có thể coi như một bài viết độc lập về chủ đề tính toán đám mây. Cuốn sách này được biên soạn với sự đóng góp của 65 chuyên gia tầm thế giới về lĩnh vực tính toán đám mây và các ứng dụng của nó. Ban Tư vấn dự án biên soạn cuốn sách này gồm 9 nhà nghiên cứu và hoạt động thực tiễn từ giới hàn lâm và giới công nghiệp, đã giúp định hình cuốn sách, lựa chọn các chủ đề hợp lý và lựa chọn các chuyên gia sáng tạo và giầu tri thức đóng góp bài viết. Phạm vi của cuốn sách gồm các bài viết về công nghệ, hệ thống và kiến trúc tính toán đám mây, các dịch vụ tính toán đám mây tiên phong, cùng các kiểu ứng dụng tính toán đám mây.

Cuốn sách trên trang web của NXB: http://www.springer.com/computer/communication+networks/book/978-1-4419-6523-3.

Tải về…

1. Cloud Computing Fundamentals – Handbook of Cloud Computing. Springer Press. Vietnamese 11.03.03

Tiếp tục đọc

Advertisements

Bạn nghĩ gì về bài viết này?

Filed under Tủ sách Công nghệ thông tin

Download “Software Requirements Best Practices”, Microsoft Press – Bản dịch tiếng Việt

Để 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. Tiếp tục đọc

2 phản hồi

Filed under Tủ sách Công nghệ thông tin

Software Requirements. First Edition – MS Press. Chương 5 – Yêu cầu phần mềm và quản lý rủi ro

Tác giả: Karl E. Wiegers

Người dịch: Hoàng Xuân Thịnh

Dave, quản lý dự án của Chemical Tracking System tại Contoso Pharmaceuticals, đang có cuộc gặp với trưởng nhóm lập trình Helen và trưởng nhóm kiểm thử Ramesh. Tất cả đều đang vui mừng về dự án mới và họ nhớ lại một số vấn đề đã gặp trong dự án trước đây gọi là Pharm-Simulator.

“Hãy nhớ lại xem chúng ta đã không phát hiện ra người dùng ghét cái giao diện của Simulator như thế nào cho đến tận lần kiểm thử beta?” Helen hỏi. “Chúng ta đã mất 5 tuần để xây dựng lại hệ thống và kiểm thử lại. Tôi không hề muốn lặp lại việc đó một lần nữa.”

“Chả vui vẻ tí nào cả”, Dave nói. “Điều khó chịu nữa là người dùng nói họ muốn rất nhiều tính năng nhưng thực tế thì chả ai sử dụng sau này cả. Vậy hãy trao đổi với họ ít nhất 3 lần trước khi biết chúng ta có nên viết một tính năng nào đó, nếu không hãy bỏ nó đi ngay. Vớ vẩn thật!”

“Chúng ta đã xông vào Simulator quá sớm và không có đủ thời gian để viết các yêu cầu chi tiết,” Ramesh nhớ lại. “Một nửa thời gian của mấy ông kiểm thử là đi hỏi mấy ông lập trình xem chương trình có những tính năng nào để mà kiểm thử. Đến khi kiểm thử lại thấy là các chức năng mà mấy ông lập trình đã viết lại hoàn toàn  không phải là cái mà người dùng mong muốn.”

“Tôi thật sự bực bội khi bà quản lý bộ phận đề nghị xây dựng Pharm-Simulator đã ký trên bản yêu cầu mà chẳng hề đọc qua xem nó thế nào”, Dave thêm vào. “Cho đến khi chúng ta nhận được cả dòng thác các đề xuất và thay đổi yêu cầu từ những người thuộc bộ phận ấy. Chả có gì ngạc nhiên khi dự án chậm đến 4 tháng và chi phí thì hầu như tăng gấp đôi so với ngân sách. Nếu điều đó xảy ra lần nữa, chắc tôi điên mất!”

Ramesh đề nghị. “Hay là chúng ta lập một danh sách các vấn đề mà ta đã gặp trong Simulator từ đó ta dễ tránh được các vấn đề tương tự có thể có trong dự án Chemical Tracking System. Tôi đã đọc một bài báo về quản lý rủi ro phần mềm, họ khuyên chúng ta nên chỉ ra các rủi ro và phác thảo kế hoạch phòng ngừa chúng.”

“Tôi không biết về cái đó,” Dave nói. “Chúng ta đã học được rất nhiều từ Simulator và chúng ta đều không muốn các vấn đề tương tự như vậy từ dự án này nữa. Dự án này không lớn đến mức cần phải quản lý rủi ro. Nếu chúng ta viết ra những gì có thể gây rắc rối cho Chemical Tracking System thì điều đó có vẻ như là tôi không biết làm thế nào để thực hiện dự án một cách thành công. Tôi không muốn bất cứ những suy nghĩ trái chiều nào đối với dự án này. Chúng ta cần phải lập kế hoạch cho dự án thành công!”

Tiếp tục đọc

%(count) bình luận

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

Software Requirements. First Edition – MS Press. Chương 4: Cải tiến quy trình yêu cầu của bạn – Kỳ 2

Tác giả: Karl E. Wiegers

Người dịch: Hoàng Xuân Thịnh

V. TÀI SẢN QUY TRÌNH YÊU CẦU (REQUIREMENTS PROCESS ASSETS)

Nếu bạn muốn các dự án được hoàn thành với các kết quả tốt hơn thì bạn cần có các quy trình hiệu quả trên toàn bộ các giai đoạn của công nghệ yêu cầu: suy luận, phân tích, đặc tả, kiểm tra, quản lý. Tập hợp các quy trình thực hiện các công việc trên được gọi là tài sản quy trình. Một quy trình hướng dẫn các hành động mà bạn cần thực hiện để có được các kết quả mà bạn cần chuyển giao; tài sản quy trình giúp các bên liên quan tới dự án thực hiện nhất quán và hiệu quả công việc của họ. Tài sản quy trình gồm các loại tài liệu sau:

Tiếp tục đọc

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

Software Requirements. First Edition – MS Press. Chương 4: Cải tiến quy trình yêu cầu của bạn – Kỳ 1

Tác giả: Karl E. Wiegers

Người dịch: Hoàng Xuân Thịnh

Lời người dịch
Trong chương này, căn cứ trên các hướng dẫn thực hành (practices) của chương 3, tác giả đề xuất với bạn một lộ trình cải tiến quy trình yêu cầu cho các dự án công nghệ thông tin của chính bạn.

Để thúc đẩy quyết tâm cải tiến của bạn, tác giả nêu ra hai lý do sau:

  • Quy trình yêu cầu là trái tim của một dự án thành công.
  • Quy trình yêu cầu ảnh hưởng đến nhiều nhóm người khác nhau liên quan đến dự án.

Với vai trò là trung tâm của dự án, tác giả kê ra các quy trình xoay quanh quy trình yêu cầu:

  • Quy trình lập kế hoạch dự án.
  • Quy trình giám sát và kiểm soát dự án.
  • Quy trình kiểm soát thay đổi.
  • Quy trình kiểm thử hệ thống.
  • Quy trình làm tài liệu cho người dùng hệ thống.
  • Quy trình thi công hệ thống.

Và sự ảnh hưởng của quy trình yêu cầu đối với những nhóm người liên quan (stakeholdes) tới dự án:

  • Nhóm marketing.
  • Nhóm hỗ trợ kỹ thuật.
  • Nhóm phụ trách người dùng.
  • Nhóm kỹ thuật phần cứng.

Sau khi đã nhấn mạnh lý do cải tiến quy trình yêu cầu, để tăng khả năng thành công, tác giả trình bày 4 nguyên lý – tức 4 cơ sở cho hành động cải tiến như sau:

  • Cải tiến quy trình cần được thực hiện theo kiểu tiến hoá, liên tục và có chu trình.
  • Con người và các tổ chức chỉ thay đổi khi họ bị thúc ép phải thay đổi.
  • Các thay đổi quy trình cần có mục đích rõ ràng.
  • Coi các hoạt động cải tiến như là các tiểu dự án.

Tiếp theo, tác giả đề xuất  một chu trình cải tiến mà bạn có thể dùng cho các dự án của  mình, đặc biệt có những bảng hỏi và template rất cụ thể.

Quy trình yêu cầu, trên thực tế là một tập hợp nhiều quy trình con khác nhau, tác giả gọi chúng là các tài sản quy trình – nói theo ngôn ngữ của doanh nghiệp, tất cả những gì được dùng để sản xuất ra sản phẩm thì gọi là tài sản của doanh nghiệp. Cải tiến quy trình chính là làm mới hoặc cải tiến các tài sản này. Có hai loại tài sản quy trình yêu cầu: các quy trình phát triển yêu cầu và các quy trình quản lý yêu cầu.

Cuối cùng tác giả trình bày một lộ trình cải tiến yêu cầu và cho rằng không có công thức cải tiến chung cho tất cả, bạn phải cụ thể hóa lộ trình cải tiến cho chính mình.

Chương này sẽ được chia thành 2 kỳ.

Tiếp tục đọc

4 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

Software Requirements. First Edition – MS Press. Chương 3: Good Practices cho công nghệ yêu cầu – Kỳ 2

Tác giả: Karl E. Wiegers

Người dịch: Hoàng Xuân Thịnh

III. PHÂN TÍCH YÊU CẦU (REQUIREMENTS ANALYSIS)

Phân tích yêu cầu bao gồm việc làm mịn, phân tích ý tưởng và lời lẽ, nghiên cứu kỹ lưỡng các yêu cầu đã thu thập được để đảm bảo chắc chắn tất cả stakeholders (những người có liên quan) hiểu điều họ muốn nói, để tìm kiếm các lỗi, các thiếu sót và thiếu hụt khác. Công việc phân tích yêu cầu cũng đánh giá liệu các yêu cầu và SRS  (tài liệu đặc tả yêu cầu phần mềm) có đáp ứng đầy đủ các đặc tính về yêu cầu tuyệt vời được viết ở Chương 1 hay không. Mục đích của bạn là phát triển các yêu cầu chất lượng và chi tiết đủ để có thể xây dựng các ước lượng đầu vào cho dự án chuẩn bị tiến hành và để thực hiện việc thiết kế, xây dựng, kiểm thử sản phẩm.

Tiếp tục đọc

%(count) bình luận

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

Software Requirements. First Edition – MS Press. Chương 3: Good Practices cho công nghệ yêu cầu – Kỳ 1

Tác giả: Karl E. Wiegers

Người dịch: Hoàng Xuân Thịnh

Lời người dịch
Con người hiện đại thực hiện công việc của mình theo cách sau: hình thành lý thuyết trước và sau đó dùng lý thuyết này để hướng dẫn cho hành động. Tuy nhiên, mọi lý thuyết khi thực hiện các tính toán – hiểu theo nghĩa rộng, không phải chỉ là tính toán toán học – đều chỉ xét đến những tham số cơ bản, cốt lõi mà tạm bỏ qua những tham số chi tiết hoặc tham số đặc thù. Nguyên nhân chủ yếu vì nếu tính đến những tham số đó thì sự tính toán sẽ quá phức tạp, không thể kham nổi. Vì vậy, khi áp dụng lý thuyết, những người làm thực hành mới điều chỉnh dần lý thuyết cùng với sự tham gia của các tham số chi tiết và đặc thù của môi trường thực tế. Kết quả đạt được sau những điều chỉnh lý thuyết trên hàng trăm, hàng nghìn ứng dụng thực tế là những gì được gọi là “best practices”các hướng dẫn thực hành tốt nhất. Tuy nhiên, trong nhiều trường hợp, vì nhiều lý do, người ta chỉ gọi những hướng dẫn thực hành đó là “good practices”, như gần đây báo chí Việt Nam hay nói tới các hướng dẫn thực hành nhà thuốc tốt (GPP – Good Pharmacy Practices), hay các hướng dẫn thực hành nông nghiệp tốt (GAP – Good Agriculture Practices).

Trong Chương 3 này, tác giả sẽ trình bày các hướng dẫn thực hành tốt cho công nghệ yêu cầu  đã được đúc rút từ rất nhiều dự án IT thực tế, bao gồm 40 practices được chia thành 7 nhóm: trang bị tri thức, quản lý yêu cầu, quản lý dự án, suy luận yêu cầu, phân tích yêu cầu, đặc tả yêu cầu, kiểm tra yêu cầu.

Tiếp theo tác giả trình bày một thứ tự ưu tiên và mức độ khó khăn khi áp dụng mỗi practice để thực thi công nghệ yêu cầu. Từ đó trong Chương 4, tác giả sẽ trình bày cách thức thiết lập một lộ trình cải tiến quy trình yêu cầu dựa trên 40 practices này.

Sau đó, mỗi practice được mô tả ngắn gọn và chỉ ra chương nào trong cuốn sách sẽ thảo luận chi tiết về nó để người đọc bám sát ý tưởng cần thực hiện.

Một số lưu ý về thuật ngữ tác giả dùng:

  • Thuật ngữ “giáo dục” (educate), ví dụ “Giáo dục cho đại diện người dùng và các nhà quản lý về yêu cầu”. Tác giả muốn nhấn mạnh mục đích của giáo dục là tạo ra nhận thức về tầm quan trọng của một vấn đề, tất cả mọi người phải hiểu lý do vì sao phải triển khai vấn đề đó, việc thực thi vấn đề không được đặt ra.
  • Thuật ngữ “đào tạo” (train), ví dụ “Đào tạo các nhà phân tích yêu cầu”. Tác giả muốn nhấn mạnh mục đích của đào tạo là hướng dẫn thực thi một vấn đề.
  • Thuật ngữ “truyền thông” (communication) được tác giả dùng để chỉ sự trao đổi nhằm tạo ra sự thông hiểu lẫn nhau giữa những người liên quan trong cùng một dự án (stakeholders) – khách hàng, người phân tích, người phát triển, chủ đầu tư dự án,…

Nhiều thuật ngữ thông dụng trong công nghệ phần mềm, người dịch vẫn để nguyên tiếng Anh. Chương này sẽ được đưa thành 2 kỳ.

Tiếp tục đọc

2 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