Nâng cao chất lượng dự án với Rational Team Concert 3.0 và ODC: Nâng cao chất lượng dự án với Rational Team Concert 3.0 và ODC:

Phần 1. Phân loại và xác nhận hợp lệ các lỗi

Việc sử dụng Phân loại lỗi trực giao (ODC) cho các phân tích trong suốt chu kỳ phát triển phần mềm mang lại cho nhóm phát triển một cái nhìn sâu hơn vào các xu hướng lỗi và công việc tồn đọng lỗi. Bộ các chức năng phân tích của ODC có thể làm phong phú thêm hầu hết tất cả các quá trình phát triển phần mềm. Bài này, bài đầu tiên trong loạt bài hai phần này, cho thấy cách mở rộng Phiên bản 3.0 Rational Team Concert™ (Phối hợp nhóm Rational) của IBM® để hỗ trợ thu thập dữ liệu lỗi hệ thống của ODC.

Anna Bizoń Adamczyk, Kỹ sư phần mềm, IBM China

Anna Bizoń-AdamczykAnna Bizon-Adamczyk là một kỹ sư phần mềm cho Phòng thí nghiệm phần mềm Krakow của IBM, ở Ba Lan. Cô đã gia nhập IBM vào năm 2006. Cô quan tâm đến việc quản lý dự án và các hoạt động liên quan đến cấu hình Rational Team Concert để theo dõi tiến độ dự án và báo cáo trạng thái.



26 04 2012

Bài này giải thích cách sử dụng các tính năng của Phiên bản 3.0 Rational Team Concert™ của IBM® của IBM để thu thập dữ liệu Phân loại lỗi trực giao (ODC) để phân tích thêm. Đây là bài đầu tiên trong loạt bài mô tả các bước cần thiết để chạy quá trình ODC trong một môi trường Rational® Jazz™ của IBM®, về các khả năng công cụ để thu thập dữ liệu ODC. Bài thứ hai sẽ mô tả cách tạo một bộ các biểu đồ đánh giá và làm cho chúng có sẵn cho tất cả các thành viên của nhóm trong một môi trường Rational Team Concert.

Các điều kiện tiên quyết

Để làm theo các hướng dẫn trong bài này, bạn cần có một máy chủ Rational Team Concert 3.0 đã cài đặt và một máy khách Rational Team Concert Eclipse tương ứng đã cấu hình. Bạn cũng sẽ cần các quyền hạn để thay đổi định nghĩa quá trình. Nếu bạn chưa có Phiên bản 3.0 của máy chủ hoặc máy khách Rational Team Concert, xin vui lòng xem phần Resources của bài này để tìm thông tin về nhận, cài đặt và cấu hình phần mềm cần thiết từ trang web Jazz.


Các lợi ích của ODC

Phân loại lỗi trực giao (ODC) là một phương pháp phân tích lỗi mạnh mẽ mà các nhóm phát triển có thể sử dụng để theo dõi tiến độ và tình trạng sức khỏe của dự án. Kỹ thuật này được nhóm Nghiên cứu của IBM phát triển. Quá trình ODC đã được áp dụng có hiệu quả cho nhiều dự án, đã cho thấy rằng nó góp phần cung cấp thành công phần mềm chất lượng cao. ODC được xây dựng từ một bộ các quy tắc đơn giản để phân loại lỗi, có thể dễ dàng thích nghi với hầu hết bất kỳ dự án nào. Sự đơn giản của phương pháp ODC làm giảm các chi phí phát sinh khi đưa nó vào chu kỳ phát triển phần mềm. Kết quả là, nó cung cấp giá trị thực sự cho khách hàng và các nhóm phát triển. Tóm lại, sau khi tích hợp ODC với môi trường phát triển của bạn, bạn có khả năng nhận thấy những tiến bộ đáng kể trong quá trình theo dõi tiến độ dự án, quản lý rủi ro và chất lượng, khiến khách hàng hài lòng nhiều hơn.

Giả định chính của ODC là mở rộng cho mỗi bản ghi lỗi có một bộ dữ liệu bổ sung được định rõ. Thực ra nhiều thông tin hơn luôn có nghĩa là các quyết định tốt hơn. Sau một khoảng thời gian nhất định, dữ liệu ODC được thu thập có hệ thống và toàn diện cho từng lỗi sẽ cho phép nhóm phát triển thực hiện một phân tích rộng rãi về đặc điểm của các lỗi được tìm thấy trong các hoạt động phát triển khác nhau và phân tích các xu hướng lỗi. Phân tích này dẫn đến việc xác định các vấn đề chủ yếu. Tiếp đến phần quan trọng nhất: các hành động để ngăn chặn các sự cố tiếp theo trong các tình huống không mong muốn.

Thông tin ngữ nghĩa ODC không chỉ dẫn đến các quyết định tốt hơn, mà còn dẫn đến giảm chi phí đáng kể. Đây là một con đường đơn giản và hiệu quả để nâng cao chất lượng phần mềm bằng cách phòng ngừa lỗi, tăng cường loại bỏ lỗi ngay từ đầu và giảm tỷ lệ rò lỗi. Phân tích ODC có thể trả lời một tập các câu hỏi rộng lớn, thường được hỏi trong quá trình phát triển, ví dụ:

  • Chúng tôi có tìm ra đúng lỗi trong từng hoạt động không?
  • Các lỗi thường nằm ở đâu?
  • Việc thử nghiệm chưa bao hàm điểm nào?
  • Chất lượng mã nguồn và thử nghiệm quá hạn là gì?
  • Chúng tôi có nhận được đúng mức chú ý của khách hàng không?
  • Chúng tôi đang có tiến triển về tính toàn vẹn mã của mình không?
  • Chúng tôi sắp đạt tới sự ổn định tốt hơn cho sản phẩm của mình chưa?

ODC trong hoạt động

Quá trình đánh giá và phân loại ODC đầy đủ được xác định rõ ràng và gồm có bốn giai đoạn chính được thể hiện trong Hình 1.

Hình 1. Các giai đoạn quá trình chính của ODC
Sơ đồ nối tiếp bốn hoạt động

Quá trình này gồm các hoạt động sau, xảy ra theo thứ tự dưới đây:

  1. Phân loại. Bước phân loại để nắm bắt việc thu thập dữ liệu ODC. Việc thu thập dữ liệu yêu cầu một cam kết nhóm với hai vai trò cơ bản: một Submitter (Người trình) và một Responder (Người trả lời). Người thử nghiệm thường nhận vai trò của Submitter, trong khi các thành viên trong nhóm phát triển thường gắn với các phần Responder. Phân loại là một quá trình không đổi về việc gán các thuộc tính đúng cho một thực thể lỗi.
  2. Xác nhận hợp lệ. Bước này phải được thực hiện bởi một người có đủ trình độ chuyên môn với bộ các kỹ năng thích hợp về kiến thức và ODC đặc trưng cho dự án. Vai trò của Người xác nhận hợp lệ (Validator) là cung cấp thông tin phản hồi cho nhóm phát triển, dựa trên kết quả đánh giá các lỗi đã phân loại.
  3. Đánh giá. Về mặt ODC, đánh giá này được tập trung vào những mối quan hệ giữa các thuộc tính ODC và dữ liệu có liên quan đến lỗi khác, như thành phần hoặc mức độ nghiêm trọng. Nó thường gồm có hoặc phân tích xu hướng lỗi cho các lỗi do thuộc tính ODC nào đó hoặc phân tích dựa trên số lượng các lỗi có một bộ thuộc tính nào đó trong thuộc tính ODC khác.
  4. Hành động. Đây là giai đoạn thực hiện các hành động là một kết quả của tất cả các phân tích các lỗi đã phân loại.

Bài này tập trung vào các giai đoạn Phân loại Xác nhận hợp lệ về mặt cho phép các tính năng thích hợp trong Rational Team Concert hỗ trợ lược đồ ODC cho các mục công việc của một kiểu lỗi.

Các hướng dẫn thành công của ODC
Đây là tất cả các nhân tố quan trọng để đảm bảo cho phương pháp luận ODC thành công trong dự án của bạn:
  • Cam kết nhóm phát triển về phương pháp luận ODC.
  • Kiến thức phù hợp, vì kiến thức thiếu hụt có thể dẫn đến dữ liệu không đúng.
  • Các lỗi phải được tất cả các thành viên trong nhóm phân loại theo hệ thống.
  • Việc xác nhận hợp lệ được thực hiện thường xuyên và thông tin phản hồi được cung cấp cho các thành viên trong nhóm.
  • Việc đánh giá được thực hiện và dẫn đến việc xác định các hành động cần thiết được thực hiện trong môi trường nhóm phát triển. Các công cụ này được cấu hình và hỗ trợ đúng cho quá trình này ở tất cả các giai đoạn.

Các khái niệm phân loại lỗi

Khái niệm phân loại ODC phải được giới thiệu để hiểu môi trường phát triển cần được cấu hình như thế nào. Vòng đời lỗi thường có một số trạng thái trong chu kỳ phát triển, nhưng chỉ có thể lấy ra các thông tin có ích hai lần: một lần khi phát hiện ra lỗi và một lần khi nhà phát triển cung cấp bản sửa lỗi.

Khi nhận ra một lỗi, Submitter phải thu thập tất cả thông tin cần thiết và ghi lại nó vào công cụ dò lỗi trước khi chuyển lỗi đó tới hàng đợi phát triển. Thông thường ở giai đoạn này, mức độ nghiêm trọng và thông tin liên quan đến lỗi khác được cung cấp. Mặc dù tất cả các dữ liệu là rất có ích trong việc phân tích lỗi, thông tin có thể được mở rộng cùng với một bộ dữ liệu ODC ban đầu. Có ba thể loại đặc thù với ODC nắm bắt các tình huống khi lỗi bắt đầu xảy ra. Với một người trình lên một lỗi, có thể sử dụng ba thể loại sau để phân loại lỗi:

Hoạt động
Hoạt động được thực hiện tại thời điểm phát hiện ra lỗi. Một nhóm dự án sẽ xác định bộ các hoạt động có sẵn.
 
Trigger
Điều kiện được thực hiện khi lỗi được phát hiện, hoàn toàn phụ thuộc vào hoạt động. Khi hoạt động phụ thuộc vào dự án cụ thể, bộ các trigger vẫn giữ nguyên không thay đổi.
 
Ảnh hưởng
Đánh giá về ảnh hưởng của lỗi đối với khách hàng.
 

Khi Responder kết thúc lỗi, dữ liệu bổ sung được tạo sẵn để mô tả chính xác tính chất và phạm vi của lỗi. Thông tin này đã được phân chia thành một trong năm loại sau:

Đích
Thực thể đã được sửa lỗi
 
Kiểu lỗi
Bản chất của việc sửa lỗi
 
Vòng phân loại
Nguyên nhân trực tiếp của lỗi
 
Nguồn gốc
Xác định nguồn gốc của đích đã có lỗi.
 
Tuổi
Lịch sử của đích
 

Lưu ý:
Các tập con thông tin do từng vai trò điền vào là thông tin dùng riêng. Rational Team Concert nên được cấu hình để giúp giữ cho chúng tách rời nhau. Đây là một trong những mục đích của chúng ta.


Rational Team Concert và phân loại dữ liệu lỗi

Từ ngày xuất bản đầu tiên bài này, Rational Team Concert không hỗ trợ phân loại lỗi ODC khi bạn nhận được nó; tuy nhiên, có rất nhiều cách mở rộng chức năng để đạt được mục tiêu này. Bằng cách mở rộng nền tảng Rational Team Concert, bạn có thể cải thiện nó với quá trình ODC.

Để thực hiện việc thu thập dữ liệu ODC trong Rational Team Concert, bạn sẽ mở rộng tạo phẩm mục công việc của Rational Team Concert bằng cách định nghĩa các thuộc tính tùy chỉnh (đây là một khả năng tự nhiên của Rational Team Concert). Điều này hoàn toàn phù hợp với sự đơn giản của mô hình dữ liệu ODC, được tập trung vào một bộ các thuộc tính liên quan đến lỗi được định rõ.

Để cho phép thu thập dữ liệu ODC, bạn cần tùy chỉnh Defect type (kiểu Lỗi) của mục công việc. Để làm điều này, hãy chạy máy khách Rational Team Concert Eclipse và một định nghĩa hay khuôn mẫu dự án đã chọn trong Process Configuration Editor (Trình soạn thảo cấu hình tiến trình). Bạn sẽ làm việc với phần Work Items (Các mục công việc) của Process Configuration (Cấu hình tiến trình) :
Project Configuration > Configuration Data > Work Items

Các kiểu liệt kê

Trước tiên, bạn sẽ cần thêm các kiểu liệt kê cần thiết cho các thuộc tính ODC. Quá trình tạo một kiểu liệt kê mới được trình bày trong ví dụ ODC Activity (Hoạt động ODC) sau:

  1. Mở trình soạn thảo Enumerations (Các kiểu liệt kê) và, trong các thẻ mở ra, chuyển đến Choose enumeration to edit (Chọn kiểu liệt kê để chỉnh sửa) và nhấn Add (Thêm).
  2. Một cửa sổ hộp thoại xuất hiện, như trong Hình 2, vì vậy bạn có thể cung cấp Mã định danh (ID) của kiểu liệt kê và tên của nó. Sau khi bạn nhập thông tin và nhấn OK, kiểu liệt kê mới có sẵn để chỉnh sửa.
Hình 2. Thêm một kiểu liệt kê mới cho ODC Activity
Các trường ID của kiểu liệt kê: ID, Name

Bây giờ bạn có thể xác định các giá trị chữ của kiểu liệt kê và thứ tự của chúng bằng cách thêm chúng vào danh sách Enumeration Literals (Các giá trị chữ của kiểu liệt kê).

  1. Bằng cách nhấn Add Literal (Thêm giá trị chữ) cho mỗi mục nhập kiểu liệt kê, bạn xác định các giá trị chữ, gồm cả "Unassigned" (Không được gán).
  2. Sau đó, trong phần Enumeration, thiết lập Default Literal (Giá trị chữ mặc định) và Unassigned Literal (Giá trị chữ không được gán) tới Unassigned, như trong Hình 3.
Hình 3. Thêm các giá trị chữ vào kiểu liệt kê
Trình đơn thả xuống chữ không gán và chữ mặc định

Lặp lại các bước trên để tạo các kiểu liệt kê cho phần còn lại của các kiểu liệt kê cần thiết cho các thuộc tính ODC. Bảng 1 và Bảng 2 cho thấy các mục nhập giá trị chữ cho mỗi kiểu liệt kê cần được tạo ra. Bảng 3 cho thấy các ID và các tên của kiểu liệt kê.

Bảng 1. Các giá trị chữ của kiểu liệt kê cho các thuộc tính ODC Submitter
ODC Activity (Hoạt động ODC)ODC TriggerODC Impact (Ảnh hưởng ODC)
Không được gán
Xem xét lại thiết kế
Kiểm tra mã
Kiểm tra đơn vị
Xây dựng
BVT
CVT
SVT
IVT
GVT
TVT
DBCS IVT
Hiệu năng
Khả năng mở rộng
Xem xét lại ID
Xem xét lại GUI (Giao diện người dùng đồ họa)
Chấp nhận
Thử nghiệm bê-ta
Không được gán
Tuân theo thiết kế
Logic, lưu lượng
Tương thích ngược
Tương thích bên
Xảy ra đồng thời
Tài liệu nội bộ
Phụ thuộc ngôn ngữ
Tác dụng phụ
Các tính huống hiếm có
Đường dẫn đơn giản
Đường dẫn phức tạp
Bao trùm
Biến thể
Trình tự
Tương tác
Tải công việc, căng thẳng
Phục hồi, ngoại lệ
Khởi động, khởi động lại
Cấu hình phần cứng
Cấu hình phần mềm
Các ký tự, văn bản màn hình
Chuyển hướng
Widget, hành vi GUI
Không được gán
Khả năng cài đặt
Các tiêu chuẩn
Khả năng dịch vụ
Số nguyên
An toàn
Di trú
Độ tin cậy
Hiệu năng
Tài liệu
Các yêu cầu
Bảo trì
Tiện lợi
Khả năng truy cập
Khả năng
Bảng 2. Các giá trị chữ của kiểu liệt kê cho các thuộc tính ODC Responder
ODC target (Đích ODC)ODC defect type (Kiểu lỗi ODC) ODC qualifier (Vòng loại ODC)ODC age (Tuổi ODC)ODC source (Nguồn ODC)
Không được gán
Các yêu cầu
Thiết kế

Xây dựng, đóng gói
Phát triển thông tin
Hỗ trợ ngôn ngữ quốc gia
Không được gán
Gán
Kiểm tra
Thuật toán, phương thức
Chức năng, lớp, đối tượng
Định giờ, nối tiếp hóa
Giao diện, các thông báo hướng đối tượng
Mối quan hệ
Giao diện người dùng
Chuyển dịch
Không được gán
Thiếu
sai
Không liên quan
Không được gán
Cơ bản
Mới
Được viết lại
Được sửa lại
Không được gán
Được phát triển nội bộ
Được dùng lại từ thư viện
Được thuê ngoài
Được chuyển
Bảng 3. Các tên và các mã định danh của thuộc tính tùy chỉnh ODC
TênID (Mã định danh)
ODCActivityodc.activity
ODCTriggerodc.trigger
ODCImpactodc.impact
ODCTargetodc.target
ODCDefectTypeodc.deftype
ODCQualifierodc.qualifier
ODCAgeodc.age
ODCSourceodc.source

Các kiểu liệt kê đã tạo ra được sử dụng như một kiểu dùng cho thuộc tính tùy chỉnh lỗi ODC.

Các thuộc tính tùy chỉnh

Khi bạn có tất cả các kiểu liệt kê cần thiết được xác định, bạn có thể thêm các thuộc tính tùy chỉnh ODC tới Defect work item (Mục công việc lỗi). Để làm điều này hãy làm theo các hướng dẫn sau:

  1. Mở Types and Attributes (Các kiểu và các thuộc tính) và chắc chắn đã chọn kiểu Defect của mục công việc.
Hình 4. Trình soạn thảo Types và Attributes
Các kiểu và các thuộc tính, lỗi và trình soạn thảo công việc
  1. Cuộn đến phần Attributes của trình soạn thảo Types and Attributes và chọn Show only custom attributes (Chỉ hiện thị các thuộc tính tùy chỉnh).
  2. Nhấn Add.
  3. Trong cửa sổ mới (xem Hình 5), cung cấp các thông tin cần thiết cho thuộc tính tùy chỉnh ODC Activity, gồm cả kiểu liệt kê thích hợp và ID giống như đã được sử dụng cho kiểu liệt kê tương ứng.
Hình 5. Tạo một thuộc tính tùy chỉnh mới
Cửa sổ hộp thoại Add Custom Attribute
  1. Lặp lại bước 1 và 2 cho phần còn lại của các thuộc tính ODC.

Tùy chính của Trình soạn thảo trình bày lỗi (Defect Presentation Editor)

Khi tất cả các thuộc tính ODC Submitter được tạo ra, bạn cần mở rộng Trình soạn thảo lỗi (Defect editor) để nó hiển thị dữ liệu ODC. Trước đó, bạn cần phải xác định một vùng giao diện người dùng cho Trình soạn thảo lỗi, nơi bạn có thể chỉnh sửa dữ liệu ODC. Để làm điều này:

  1. Mở phần Types and Attributes kiểm tra xem đã chọn tùy chọn Defect chưa, hãy chắc chắn rằng đã chọn mục Defect trong mục Work Item Types và kiểm tra ID của trình soạn thảo nào được hiển thị trong phần Work Item Editor (Trình soạn thảo mục công việc). Hình 4, ở trên, cho thấy cấu hình của các kiểu và các thuộc tính.
  2. Mở Editor Presentations (Các cách trình bày của Trình soạn thảo) và chọn cách trình bày phù hợp với Defect.
  3. Nhấn nút Add Tab (thêm Bảng) và đưa vào các Title (Tiêu đề), Layout (Bố trí) và ID trong các phần thích hợp (xem Hình 6).
  4. Nhấn OK.
Hình 6. Thêm một thẻ ODC vào trình soạn thảo trình bày lỗi
hộp thoại add tab
  1. Nhấn Add Section (Thêm phần), đặt tên nó là ODC Submitter rồi chọn một trong các tùy chọn khe cắm.
  2. Lặp lại các bước trước để thêm phần ODC Responder.
  3. Đối với phần ODC Submitter, thêm các cách trình bày cho ODC Activity, ODC TriggerODC Impact. Nút Add Presentation hiển thị một hộp thoại để tạo cách trình bày. Trong phần Attribute-based Presentation (Cách trình bày dựa vào thuộc tính), chọn một thuộc tính thích hợp và trong Kind (Loại) thả xuống, chọn Enumeration. Theo tùy chọn bạn có thể nhập một nhãn, mô tả và ID.
Hình 7. Thêm cách trình bày trình ODC Activity tới phần ODC Submitter
Cửa sổ hộp thoại Add Presentation
  1. Trong phần ODC Responder, thêm ODC Target, ODC Defect Type, ODC Qualifier, ODC AgeODC Source.
  2. Tạo một lỗi mẫu mới và kiểm tra xem thẻ ODC và các phần đã được tạo ra đúng chưa.

Các kiểu liệt kê phụ thuộc

Cũng có thể phản ánh các phụ thuộc giữa các thuộc tính ODC trong thẻ ODC của nhà cung cấp lỗi. Một mối quan hệ, giữa ODC Activity và ODC Trigger, được hiển thị trong phần Submitter. Một mối quan hệ khác, giữa ODC Target và ODC Defect Type, cũng được hiển thị trong phần ODC Responder.

Các giá trị có thể của ODC Trigger phụ thuộc vào giá trị hiện tại của ODC Activity. Có thể thấy tương tự như vậy trong trường hợp của cặp ODC Target và ODC Defect Type. Bạn có thể quản lý mối quan hệ giữa chúng trong tính năng Value Sets (Các bộ giá trị) của trình soạn thảo Attribute Customization. Để xác định bộ giá trị phụ thuộc, bạn cần tạo một định nghĩa mới của bộ giá trị Dependent Enumerations và chọn các kiểu liệt kê. Với mỗi lựa chọn từ kiểu liệt kê nguồn, bạn có thể kiểm tra các giá trị nên có sẵn trong bộ giá trị của kiểu liệt kê đích nếu giá trị đó được chọn. Hãy chắc chắn rằng luôn chọn Unassigned để phòng ngừa các vấn đề trong lúc khởi tạo. Hình 8 đưa ra một ví dụ về một phụ thuộc ODC Activity và ODC Trigger.

Hình 8. Bộ giá trị phụ thuộc cho ODC Activity và ODC Trigger
hộp thoại tùy chỉnh thuộc tính

Xác nhận hợp lệ ODC

Bạn cũng có thể sử dụng thẻ ODC, nằm trong trình soạn thảo lỗi, để dò vết xác nhận hợp lệ ODC. Bạn có thể sử dụng nó khi bạn muốn thêm một phần chung nơi có thể lưu trữ dữ liệu khác. Bạn có thể thấy các thuộc tính bổ sung cho biết liệu một xác nhận hợp lệ đã được thực hiện chưa và ở mức nào (kiểu liệt kê xác nhận hợp lệ ODC: Không, ODC Submitter và ODC Responder).

Bạn cũng có thể thêm một trường ODC Comments (Các chú thích ODC) để cung cấp thông tin phản hồi về một lỗi . cho một người tạo và người chủ sở hữu. Hình 9 cho thấy phần này với các trường Validation and Comments dùng cho thông tin phản hồi được trình bày trong Hình 9 và Hình 10 cho thấy kết quả trong Defect Editor.

Hình 9. Các phần bổ sung trên thẻ ODC cho các mục đích xác nhận hợp lệ
Thẻ ODC trong khung nhìn Editor Presentations
Hình 10. Hoàn thành phần mở rộng của Defect editor để dò vết và xác nhận hợp lệ dữ liệu ODC
Tóm tắt lỗi

Tóm tắt

ODC là một cách phân loại các lỗi hiệu quả và tiết kiệm thời gian đáng kể cho các nhóm dự án trong tất cả các giai đoạn dự án, nhưng chỉ khi nó được thực hiện và sử dụng đúng. Việc tích hợp đúng quá trình này với nền tảng phát triển là rất quan trọng để thành công. Như bạn có thể thấy từ bài này, Rational Team Concert 3.0 có thể được mở rộng bằng cách cho quyền bạn chấp nhận dễ dàng lược đồ ODC trong các mục công việc Lỗi và xác nhận hợp lệ các hoạt động. Trong bài tiếp theo của loạt bài này, tôi sẽ mô tả một phương pháp cho phép Rational Team Concert hỗ trợ giai đoạn phân tích ODC.

Bài tiếp theo trong loạt bài hai phần này giải thích cách mở rộng Rational Team Concert để hỗ trợ giai đoạn phân tích ODC.


Lời cảm ơn

Tôi muốn cảm ơn Michael Spisak, Kiến trúc sư Công nghệ thông tin, Chuyên gia tư vấn Công nghệ thông tin có chứng chỉ của IBM và Master Inventor, vì đóng góp kỹ thuật của ông và Witold Kopel, Justyna Drozdz và Rafal Adamczyk vì sự khích lệ và đóng góp nói chung.

Tài nguyên

Học tập

Lấy sản phẩm và công nghệ

  • Truy cập vào cộng đồng Jazz để tải về các phiên bản dùng thử Máy khách và Máy chủ Rational Team Concert 3.0 và đọc các bài viết.
  • Đánh giá phần mềm của IBM theo cách phù hợp với bạn nhất: Tải nó về dùng thử, dùng thử nó trực tuyến, sử dụng nó trong một môi trường đám mây hoặc dành một vài giờ trong SOA Sandbox để tìm hiểu cách thực hiện kiến trúc hướng dịch vụ một cách hiệu quả.

Thảo luận

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=Rational
ArticleID=811909
ArticleTitle=Nâng cao chất lượng dự án với Rational Team Concert 3.0 và ODC: Nâng cao chất lượng dự án với Rational Team Concert 3.0 và ODC:
publish-date=04262012