Đáp: Bảng từ chuẩn các thuật ngữ về Kĩ nghệ phần mềm của Viện các kĩ sư điện và điện tử – Institute of Electrical and Electronics Engineers (IEEE) định nghĩa trắc nghiệm và kiểm nghiệm là như sau: Trắc nghiệm là qui trình đánh giá một hệ thống hay cấu phần để xác định liệu sản phẩm của pha phát triển đang xét có thoả mãn các điều kiện được áp đặt tại lúc bắt đầu của pha đó không. Kiểm nghiệm được định nghĩa là qui trình đánh giá một hệ thống hay cấu phần trong hay cuối qui trình phát triển để xác định liệu nó có thoả các yêu cầu đã xác định hay không. Trắc nghiệm hỏi “Chúng ta đã xây dựng hệ thống một cách đúng đắn chưa?” còn kiểm nghiệm hỏi “Chúng ta đã xây dựng đúng hệ thống chưa?”
Để đảm bảo chất lượng và tránh thiên lệch nào đó, nhiều công ti yêu cầu những hoạt động này cần được tiến hành bởi “bên thứ ba độc lập” thay vì người đang làm việc trong dự án. IEEE xác định tính độc lập trong ba miền: độc lập kĩ thuật, độc lập quản lí, và độc lập tài chính. Người SQA, người không tham gia vào phát triển phần mềm đạt tới độc lập kĩ thuật. Do đó người SQA dùng tri thức chuyên gia của họ để đánh giá các qui trình và sản phẩm phải KHÔNG làm việc trong dự án hay báo cáo cho người quản lí dự án. Độc lập quản lí yêu cầu đáp ứng cho nỗ lực này cần được tiến hành bởi một tổ chức tách biệt với tổ chức phần mềm do đó tổ chức SQA phải KHÔNG là một phần của tổ chức phần mềm. Tổ chức SQA lựa các cấu phần của phần mềm mà họ muốn kiểm thử, chọn các kĩ thuật kiểm thử, lập lịch biểu, và lựa các vấn đề và tài liệu kĩ thuật riêng để kiểm điểm tương ứng theo các qui trình và thủ tục SQA đã xác định.
Độc lập tài chính là khó bởi vì phần lớn công việc của dự án, kể cả SQA, thường được công ti tài trợ trực tiếp. Để đáp ứng yêu cầu này, công ti phải tách việc tài trợ cho SQA khỏi tài trợ cấp cho dự án để tránh xung đột. Không có việc tách rời tài trợ, người quản lí dự án có thể loại bỏ việc cấp ngân quĩ cho SQA nếu họ không được thoả mãn với công việc của SQA hay không đồng ý với những phát hiện của nhóm này.
Để đảm bảo rằng trắc nghiệm và kiểm nghiệm được thực hiện đúng, bước đầu tiên là ban hành chính sách về SQA là người có thẩm quyền trong kiểm điểm dự án và báo cáo cho cấu trúc quản lí khác. Bước tiếp là phát triển các qui trình và thủ tục SQA để xác định rõ ràng vai trò, trách nhiệm và thẩm quyền của SQA và cách họ tiến hành công việc của mình. Bước cuối cùng là lựa những người phần mềm có kinh nghiệm và huấn luyện họ thực hiện công việc SQ. Đây là phần gian nan nhất theo một số khía cạnh, bởi vì phần lớn những người quản lí dự án không muốn mất người phần mềm có kinh nghiệm cho nên nhiều công ti thuê sinh viên mới tốt nghiệp làm việc như SQA.
Đây là sai lầm chính, không có kinh nghiệm, SQA sẽ không được kính trọng và KHÔNG thể làm việc tốt được. SQA KHÔNG phải là nghề “học trong công việc” nhưng yêu cầu càn có nhiều năm phát triển phần mềm để cho họ hiệu quả. Sự kiện khác là nhiều người phát triển phần mềm ưa thích làm việc với dự án chứ không làm kiểm điểm công việc của ai đó cho nên cũng khó tìm ra người tốt có kinh nghiệm để làm việc này. Không có SQA hiệu quả, nhiều người phát triển phần mềm bỏ qua vấn đề SQA, không tuân theo qui trình đã xác định, không kiểm thử công việc của họ một cách cẩn thận nên chất lượng bị ảnh hưởng. Không có tổ chức SQA hiệu quả, nhiều vai trò SQA thoái hoá thành việc vô dụng vận hành trong chân không trống rỗng mà chẳng ai quan tâm. Không có cơ sở cho đánh giá công việc phát triển, mọi thứ trở thành vấn đề ý kiến chứ không phải là đánh giá chất lượng thực.
Hỏi: Tại sao cải tiến phần mềm nếu doanh nghiệp không làm phần mềm mà làm chế tạo hay ngân hàng?
Đáp: Tôi muốn lưu ý bạn rằng bất kể việc bạn đang ở trong doanh nghiệp nào, bạn gần như chắc chắn phải dùng phần mềm trong mọi phần công việc hàng ngày của mình. Phần mềm giải quyết chuyện trả lương, làm hoá đơn, bán hàng, chế tạo, điều khiển sản xuất, quản lí kho v.v. Phần mềm có thể tác động tới doanh nghiệp theo nhiều cách vì chất lượng của dịch vụ của doanh nghiệp phụ thuộc phần lớn vào chất lượng của phần mềm hỗ trợ chúng. Chất lượng của phần mềm tạo ra khác biệt giữa liệu bạn đi đầu hay đi sau đối thủ cạnh tranh của mình. Có thể vấn đề phần mềm đã là điều phiền nhiễu cho bạn như máy tính hỏng hay lỗi phần mềm, nhưng trong doanh nghiệp ngày nay, việc bỏ qua vấn đề phần mềm có thể gây hại nghiêm trọng cho doanh nghiệp.
Nếu phần mềm chậm, sản phẩm sẽ chậm thì bạn có thể mất doanh nghiệp. Trong thời kì găng này, bạn không có cơ hội thứ hai để tranh biện về phần mềm hay doanh nghiệp. Bạn phải làm việc cần cù và làm việc của mình cho đúng ngay lần đầu tiên vì có thể không có lần thứ hai. Bạn phải dừng lịch biểu năng nổ không hiện thực; dừng thay đổi yêu cầu rồi trông đợi sản phẩm hoàn hảo. Dù công ti bạn đang làm kinh doanh nào cũng không thành vấn đề, bạn phải dựa vào phần mềm cho nên cải tiến phần mềm là cải tiến doanh nghiệp. Phần mềm được tích hợp đầy đủ trong nhiều doanh nghiệp thế và bạn không thể bỏ qua nó được.
Hỏi: Tại sao các công ti khoán ngoài phần mềm? Cái gì là xu hướng gì trong vài năm tới? Ai sẽ là số một trong phát triển phần mềm?
Đáp: Nhiều công ti đang khoán ngoài phần mềm bởi vì chi phí của họ ít hơn nhiền so với ở Mĩ hay châu Âu. Người lập trình từ Ấn Độ, Philippine, Trung Quốc và các nơi khác của châu Á về căn bản kiếm tiền ít hơn nhiều so với người lập trình Mĩ hay châu Âu. Tuy nhiên, trong dài hạn tôi mạnh mẽ tin tưởng chất lượng và năng suất sẽ là nhân tố chính để xác định nơi phần mềm sẽ được phát triển. Phần mềm là kinh doanh rất lớn và giống như bất kì kinh doanh nào, chi phí là một nhân tố nhưng không là nhân tố duy nhất. Tại thời điêm này khó mà dự đoán được tương lai bởi vì công nghệ phần mềm thay đổi rất nhanh nhưng dựa trên nghiên cứu của tôi, hai nước có công nghiệp phần mềm hứa hẹn nhất là Nhật Bản và Ấn Độ nhưng vẫn còn phải xem họ sẽ có tác động nào lên ngành công nghiệp phần mềm toàn cầu.
Người Nhật Bản nổi tiếng là “ý thức chất lượng” và có thể chuyển giao phần mềm với ít lỗi hơn nhiều so với phần mềm Mĩ. Nhiều nghiên cứu đã chỉ ra rằng các thực hành phần mềm Nhật Bản là cao hơn thực hành của Mĩ theo nhiều cách. Một nghiên cứu như thế về 52 phần mềm chính sản xuất ở Nhật Bản và Mĩ, kể cả NTT, Mitsubishi, Fujitsu, NEC, Hitachi, Digital Equipment Corporation, IBM và những công ti khác, đã kết luận rằng các công ti Nhật Bản có tỉ lệ dùng lại phần mềm là 34.8% trong khi các công ti ở Mĩ có tỉ lệ dùng lại là 15.4%. Bên cạnh đó, thái độ của người quản lí Nhật Bản và người quản lí Mĩ là rất khác nhau.
Người quản lí Nhật Bản coi chất lượng là nhân tố quan trọng nhất trong khi người quản lí Mĩ vẫn coi chi phí là nhân tố quan trọng nhất. Tuy nhiên, trong nhiều năm người Nhật Bản đã không thể chi phối được thị trường phần mềm như họ đã làm với phần cứng. Có nhiều lí thuyết về tại sao công nghiệp phần mềm Nhật Bản chưa bao giờ cất cánh nhưng tôi tin điều đó có lẽ là do hệ thống giáo dục ở Nhật Bản nơi việc học kiểu nhớ thuộc lòng và vâng lời quản lí cấp cao vẫn là truyền thống chính. Không có canh tân và sản phẩm mới, Nhật Bản vẫn mua nhiều phần mềm từ Mĩ thay vì xuất khẩu sang Mĩ.
Ấn Độ dường như là một đối thủ cạnh tranh tiềm năng khác với Mĩ trong ngành công nghiệp phần mềm. Xấp xỉ 80% ngành công nghiệp phần mềm hàng tỉ đô la của Ấn Độ hội tụ vào hỗ trợ cho doanh nghiệp Mĩ. Một số chuyên gia nghĩ xuất khẩu của Ấn Độ có thể vượt quá $100 tỉ vào đầu năm 2010. Hai nhân tố có thể ảnh hưởng tới thành công của Ấn Độ về phần mềm là: sự hỗ trợ của chính phủ Ấn Độ trong việc nới lỏng biểu thuế và hạn chế và chi phí thấp của việc phát triển phần mềm ở Ấn Độ.
Người lập trình Ấn Độ đang kiếm tiền ít hơn nhiều so với người lập trình Mĩ. Tuy nhiên, tôi tin rằng trong dài hạn, chi phí phát triển phần mềm ở Ấn Độ sẽ tiếp tục tăng lên khi nhiều việc hơn được khoán ngoài ra đó. Nếu ngành công nghiệp phần mềm Ấn Độ không hội tụ vào cải tiến chất lượng các sản phẩm và dịch vụ của nó, mà tiếp tục dựa vào lao động chi phí thấp của mình, Ấn Độ có thể không còn tận hưởng được vị thế là nhà cung cấp phần mềm then chốt cho thế giới nữa.
Tôi mạnh mẽ tin những người lãnh đạo phần mềm trong thập kỉ tới sẽ là những người có thể chuyển giao phần mềm chất lượng cao trong phạm vi chi phí thoả đáng.
Hỏi: Tại sao lãng phí thời gian vào cải tiến phần mềm khi chúng ta có thể mua thay vì làm? Tại sao lãng phí thời gian vào cải tiến thực hành quản lí khi chúng ta có thể khoán ngoài cho các nước khác và giảm chi phí?
Đáp: Không phải mọi thứ chúng ta cần đều có thể mua được ở thị trường mở. Nếu giảm chi phí là quan trọng cho bạn thì cải tiến phần mềm cung cấp cơ hội có ý nghĩa để giảm chi phí và cải tiến chất lượng. Phần mềm là công nghệ đáng ngạc nhiên có chi phí chế tạo bằng không, có thể được phân phối toàn thế giới trong giây phút, không bị thoái hoá, và nó là kinh doanh rất lớn ngày nay (chẳng hạn cứ nhìn vào Microsoft và Google)
Không phải mọi thứ chúng ta có thể làm đều có thể được khoán ngoài cho các nước khác. Nếu giảm chi phí là quan trọng với bạn thì cải tiến thực hành con người cung cấp cơ hội lớn để tăng năng suất và giảm chi phí. Mặc dầu, cách cổ về thuê người khi bạn cần họ và thải người khi bạn không cần họ có thể vẫn có trong tâm trí một số cấp quản lí nhưng thế giới đã thay đổi quanh họ rồi.
Ngày nay người tài giỏi nhất xin vào các tổ chức mà mọi người được đối xử với sự kính trọng vì tài của họ. Mọi người sẽ làm việc ở chỗ họ được đánh giá cao về đóng góp của họ và chỗ họ được thách thức về mặt kĩ thuật. Nếu gạt bỏ mọi người bằng khoán ngoài là cách duy nhất để giảm chi phí thì bạn bị chưng hửng đấy. Có xu hướng mới đang diễn ra bây giờ, các công ti đang vứt bỏ cách thức cổ về đối xử với mọi người như “hàng hoá” và tạo ra cách thức mới nơi hấp dẫn và duy trì tài năng là “tài sản then chốt” trong thời đại số thức.
Hỏi: Nếu phải mất nhiều năm để đạt tới các mức CMMI cao và thu được ích lợi như giảm chi phí thì tại sao chúng ta không khoán ngoài phần mềm, điều nhanh hơn và dễ hơn?
Đáp: Giảm chi phí là khái niệm tương đối, không tuyệt đối. Vâng, cắt giảm chi phí có vẻ dễ dàng thông qua khoán ngoài (tức là lao động rẻ hơn) nhưng khoán ngoài chỉ có thể hiệu quả khi tổ chức hiểu yêu cầu phần mềm của nó và có thể quản lí các hợp đồng thầu của mình cho tốt. Nếu tổ chức gặp thời kì khó khăn trong quản lí yêu cầu, kiểm soát thay đổi, hay không thể quản lí được dự án riêng của mình thì làm sao nó quản lí được hợp đồng phụ ở xa nửa vòng thế giới nơi ngôn ngữ và văn hoá khác với chúng ta? Khoán ngoài yêu cầu những kĩ năng khá mới để quản lí hợp đồng phụ mà có thể bao gồm cả việc tái cấu trúc chính kết cấu nền hiện có để khoán ngoài được hiệu quả. Tôi tin khoán ngoài không nhanh hơn, rẻ hơn hay dễ hơn việc phát triển trong nhà và chúng ta phải xem xét vấn đề tiết kiệm chi phí trong khoán ngoài rất cẩn thận.
Hỏi: Chất lượng Six-Sigma là gì và làm sao nó có quan hệ với CMMI?
Đáp: Theo định nghĩa, để đạt tới chất lượng Six Sigma, qui trình phải tạo ra không quá 3.4 lỗi trên một triệu cơ hội. Có nhiều “cường điệu” về Six Sigma nhưng rất ít tổ chức thực sự đạt tới loại chất lượng gần hoàn hảo này. Từ “Sigma” là thuật ngữ thống kê đo một qui trình đã nêu lệch bao xa so với điều hoàn hảo. Nếu bạn có thể đo được bao nhiêu lỗi bạn có trong qui trình của mình, thì bạn có thể hình dung ra cách khử bỏ chúng và tiến gần tới “không lỗi” nhiều nhất có thể được.
Tôi tin Six Sigma là tầm nhìn mà chúng ta nên cố gắng vươn tới khi thực hiện CMMI. Để đạt tới Six Sigma, tổ chức phải được dẫn lái bởi dữ liệu và hội tụ vào cách đo. Chìa khoá là giảm biến thiên qui trình, điều rất tương tự như việc sắp trật tự của các mức CMM. Theo kinh nghiệm riêng của tôi, tổ chức ở mức 4 thực sự hiểu thuộc tính chất lượng, có thể chuyển giao điều khách hàng muốn, hiểu năng lực qui trình của họ và quản lí chúng theo sự kiện và dữ liệu. Mức 5 là nơi việc tối ưu hoá qui trình xuất hiện để tạo khả năng chuyển giao kết quả Six Sigma.
Hỏi: Tại sao thầy chủ trương cải tiến ở mức tổ chức thay vì mức công ti? Sẽ dễ làm nó hơn ở mức cao hơn không?
Đáp: Làm sao bạn thay đổi hành vi của mình? Làm sao bạn mong đợi hàng trăm hay hàng nghìn người thay đổi hành vi của họ? Cải tiến bao gồm văn hoá, hành vi, cam kết và nhiều thứ nữa. Cải tiến được dẫn lái bởi mục đích của tổ chức, miền, kĩ năng và kinh nghiệm. Vì từng tổ chức đều duy nhất trong các đặc trưng này, có nhiều cách thực hiện cải tiến. Tổ chức có mục đích cải tiến thời gian ra thị trường có thể lấy cách tiếp cận khác tổ chức có mục đích sản phẩm phần mềm không lỗi. Cải tiến cũng được định nghĩa bởi miền; môi trường nhúng nơi chất lượng là mấu chốt có thể tiếp cận tới cải tiến khác với môi trường Web nơi tốc độ là mấu chốt. Kinh nghiệm và kĩ năng cũng đóng vai trò rất quan trọng trong cải tiến qui trình tổ chức. Tổ có kinh nghiệm cao tiếp cận tới thay đổi dựa trên điều có tác dụng và điều không có tác dụng. Tổ không có kinh nghiệm có thể dựa trên người lãnh đạo kĩ thuật của họ hay thành viên SEPG để hướng dẫn họ.
Để làm cải tiến thành công, từng tổ chức phải hiểu qui trình, sản phẩm, miền và mục đích của mình trước khi nó có thể lựa chọn một tập các thực hành để cải tiến qui trình của nó. Không có tập các “phép màu cải tiến” hay “giải pháp đồ hộp tức khắc” như món mì ăn liền mà bạn có thể áp dụng đại trà cho mọi tổ chức và mong đợi cải tiến thực ở mức cao hơn.
Hỏi: Cái gì là khác biệt giữa mô hình phân giai đoạn và mô hình liên tục?
Đáp: Có nhiều cách tiếp cận tới cải tiến qui trình và có vài kĩ thuật mô hình hoá. Ta hãy nhìn vào những tranh luận sôi nổi giữa cách tiếp cận theo giai đoạn và liên tục:
1) Mô hình theo giai đoạn bao gồm con đường cải tiến tường minh, từ mức này sang mức khác rõ ràng nhận diện ưu tiên cải tiến. Mô hình liên tục không chứa con đường cải tiến tường minh (Không có mức tường minh nhưng mọi thứ là liên tục)
3) Mô hình phân theo giai đoạn hỗ trợ cho tổ chức trong việt thiết lập kết cấu nền theo cách quản lí được. Nó giúp văn hoá tổ chức nhất quán với việc tạo ra chất lượng cao nhất có thể được. Hội tụ chính của mô hình liên tục là vào thay đổi trong phần tử qui trình, không vào thay đổi văn hoá hay tổ chức.
4) Mô hình phân theo giai đoạn hội tụ vào vài vấn đề sống còn mà tổ chức phải đề cập tới dựa trên năng lực của nó bởi vì tổ chức chỉ có thể đề cập thành công tới một số giới hạn các vấn đề vào mỗi lúc. Mô hình liên tục không nhất thiết hội tụ vào số giới hạn các vấn đề then chốt mà cho phép tổ chức lấy ra và chọn bất kì vấn đề nào họ muốn làm việc.
5) Mô hình phân giai đoạn biểu thị tầm nhìn chung và cái nhìn nhất trí về những vấn đề quan trọng và các bước mà tổ chức phải làm trong nỗ lực cải tiến qui trình của mình. Mô hình liên tục không chứa cái nhìn nhất trí này và tầm nhìn chung.
6) Khái niệm mức độ trưởng thành trong mô hình phân theo giai đoạn có năm mức được xác định rõ ràng, chính là cái gì đó cấp quản lí có thể dễ dàng hiểu và đặt quan hệ; do đó, không khó nắm được ý định và cam kết của họ để tiến hành nỗ lực cải tiến qui trình. (Dứt khoát có cạm bẫy của việc nhấn mạnh quá mức vào việc đạt tới mức độ trưởng thành.) Không phải là dễ có được cam kết cần thiết từ cấp quản lí để thực hiện nỗ lực cải tiến dựa trên mô hình liên tục không có các mức.
7) Trong mô hình phân giai đoạn, mức 2 cung cấp nền tảng quản lí dự án để việc chuẩn hoá tổ chức có thể xuất hiện về sau ở mức 3. Mức 3 cũng phục vụ như nền tảng cho qui trình được xác định rõ để cho mức 4 có thể hội tụ vào việc thiết lập hiểu biết định lượng và kiểm soát cả qui trình được dùng và sản phẩm được xây dựng. Tại mức 5, tổ chức có thể thực hiện cải tiến qui trình liên tục và đo được. Trong mô hình liên tục, không có mức vì nó phá vỡ mọi trật tự và ưu tiên bằng việc cho phép các yếu tố qui trình riêng được cải tiến liên tục.
Hỏi: Kĩ nghệ dùng được khớp thế nào vào trong CMMI hay nó không khớp?
Đáp: Tôi tin tính dùng được là phẩm chất trong việc dùng. Nó phản ánh phần mềm dễ học và dùng thế nào, người dùng sẽ có khả năng làm việc có năng suất thế nào, và người dùng sẽ cần hỗ trợ bao nhiêu. Đó là từ quan điểm của người dùng về chất lượng phần mềm.
CMMI là khuôn khổ để cải tiến chất lượng phần mềm. Nó là bản lộ trình để xây dựng phần mềm chất lượng từ việc quản lí dự án (mức 2) tới quản lí sản phẩm (mức 3) rồi tới quản lí qui trình (mức 4) và chung cuộc quản lí chất lượng (mức 5). Đó là từ cách nhìn của người phát triển về chất lượng phần mềm.
Tính dùng được là thuộc tính khó để xây dựng trong bất kì hệ thống phần mềm nào vì nhiều người phát triển không nhận ra rằng cảm nhận của họ về sáng tạo không cung cấp thông tin về cách người dùng sẽ phản ứng lại nó. CMMI có đề cập tới vấn đề dùng được trong quản lí yêu cầu (mức 2), Kĩ nghệ sản phẩm phần mềm (mức 3), Quản lí chất lượng phần mềm (mức 4).
Hỏi: Mặc dầu ở CMMI mức 3 từ năm 2005, tổ chức chúng tôi vẫn có vấn đề trong báo cáo hiệu năng dự án. Chúng tôi đã có tập lõi các cách đo phần mềm (kích cỡ, nỗ lực, lịch biểu và lỗi) nhưng chúng không được dùng một cách hiệu quả. Có nhiều lỗi trong việc biên soạn chúng ở mức cao hơn, cái nảy sinh trong sai lầm của chúng ta để đáp ứng với mục tiêu doanh nghiệp. Chúng tôi thường xuyên bị chậm sau lịch và chi quá ngân sách. Năm ngoái, chúng tôi đã không đạt tới việc hài lòng của khách hàng. Nỗ lực mức 4 của chúng tôi không đi thật trơn tru lắm và ngân sách SEPG bị cắt giảm nghiêm trọng. Làm sao chúng tôi bắt đầu lại được?
Đáp: Vì tổ chức của bạn đã được đánh giá năm 2005, làm sao bạn biết rằng tổ chức của mình vẫn còn ở mức 3? Bạn có đánh giá lại về sau không? Về căn bản, kết quả đánh giá chỉ hợp thức cho một thời kì (1-2 năm) và tổ chức phải đánh giá lại cứ sau mỗi 16-24 tháng. Dựa trên thông tin của bạn rằng tổ chức đã có một tập lõi các độ đo phần mềm ở mức dự án (mức 2) nhưng lại có vấn đề ở mức tổ chức, như thu thập, biên soạn, báo cáo, quản lí, tôi sẽ rất ngần ngại về việc đạt tới mức 3.
Quên chuyện nỗ lực mức 4 hay ngân sách SEPG bị cắt giảm đi. Bạn cần tái xem xét lại toàn bộ qui trình cam kết để tìm ra căn nguyên. Nếu mục đích của tổ chức của bạn chỉ là kiếm được “mức vô nghĩa” và không nghiêm chỉnh về việc đạt tới mục đích doanh nghiệp như sự hài lòng của khách hàng, kiểm soát ngân sách và cam kết lịch biểu thì tôi nghĩ việc cải tiến của bạn quả thực đang gặp rắc rối.
English version
Question: Can you define Verification and validation and the role of SQA in these activities?
Answer: The Institute of Electrical and Electronics Engineers (IEEE) Standard Glossary of Software Engineering Terminology defines verification and validation as follows: Verification is the process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. Validation is defined as the process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements. Verification asks “Did we build the system right?” and validation asks “Did we build the right system?”
To ensure quality and avoid certain bias, many companies require these activities to be conducted by an “independent third party” rather than people who work on the project. IEEE defines independence in three areas: technical independence, managerial independence, and financial independence. SQA people who are not involved in software development achieve technical independence. Therefore SQA people who use their expertise to assess the processes and products must NOT work in the project or report to the project manager. Managerial independence requires responsibility for this effort to be conducted by an organization separate from the software organization therefore the SQA organization must NOT be part of software organization. The SQA organization selects the components of the software that they wants to test, chooses testing techniques, set schedules, and selects specific technical issues and documents to review according to a defined SQA processes and procedures. Financial independence is difficult because most works on the project, including SQA, are usually funded directly by the company. To meet this requirements, company must separate the funding to SQA from funding allocate to the project to avoid conflict. Without this separate of funding, the project managers could remove SQA funding if they are not satisfied with SQA works or agreed with their findings.
To make sure that verification and validation are implemented properly, the first step was to issue a policy on SQA as the authority in review projects and report to a different management structure. The next step was to develop SQA processes and procedures to define clearly the roles, responsibilities and authority of SQA and how they conduct their works. The final step is to select experienced software people and train them to perform SQA works. This is the hardest in some respects, because most project managers do not want to lose an experienced software people so many companies hire graduated student to work as SQA. This is a major mistake, without experiences, SQA will not be respected and can NOT do a good job. SQA is NOT a “learning on the job” career but require many years of software development in order for them to be effective. Another fact is many software developers prefer to work on projects rather than reviewing somebody’s works so it is difficult to find good people with experiences to do this job. Without an effective SQA, many software developers ignores the SQA issues, do not follow the defined process, do not test their work carefully then quality will suffer. Without an effective SQA organization, many SQA roles degenerate into useless jobs which operate in an empty vacuum that nobody cares. Without basis for judgment for development works, everything becomes a matter of opinion rather than true evaluation of quality.
Question: Why improving software if the business is not software but manufacturing or banking?
Answer: I would like to remind you that regardless of the business you are in, you almost certainly use software in every part of your working day. Software handles payroll, billing, sales, manufacturing, production control, inventory management etc. Software can impact a business in many ways since the quality of the business services depend largely on the quality of the software that supporting them. The quality of software makes the difference between whether you are ahead or behind your competitors. Maybe software problems have been an annoyance to you such as computer crash or software errors but in today business, ignoring software issues can severely damage the business. If software is late, product will be late then you may lose the business. In this critical time, you do not have second chance to argue about software or business. You must work hard and do our job properly the first time since there may be no second time. You must stop setting unrealistic aggressive schedule; stop changing requirements then expect a perfect product. No matter what business your company is doing, you must rely on software so to improving software is improving the business. Software is fully integrated in so many businesses and you can not ignore it.
Question: Why are companies outsourcing software? What is the trend in the next few years? Who will be the number one in software development?
Answer: Many companies are outsourcing software because their costs are much less than in the U.S or Europe. Programmers from India, Philippine, China and other parts of Asia typically earn much lesser than American or European programmers. However, in the long term I strongly believe quality and productivity will be the key factors to determine where software will be developed. Software is a very big business and like any business, cost is one factor but not the only factor. At this time it is difficult to predict the future because software technology changes very fast but based on my research, two countries that have the most promising software industries are Japan and India but it remains to be seen what effect they will have on the global software industry.
The Japanese are well known as “quality conscious” and could deliver software with much less errors than American software. Several studies have shown that Japanese software practices are superior to those of the US in many ways. One such study of 52 of the major software produces in Japan and the US, including NTT, Mitsubishi, Fujitsu, NEC, Hitachi, Digital Equipment Corporation, IBM and others, concluded that the Japanese corporations had a software reuse rate of 34.8% while those of the US had a reuse rate of 15.4%. Additionally, the attitude of Japanese managers and US managers were very different. The Japanese managers consider quality as the most important factor where US manager still consider cost as the most important factor. However, for many years Japanese could not dominate the software market as they did with hardware. There are many theories on why Japanese software industry never takes off but I believe it probably due to the education systems in Japan where rote memorization and obey senior management are still the main tradition. Without innovation and new products, Japan still buy a lot of software from the U.S instead of export to the U.S.
India appears to be another potential competitor with the US in the software industry. Approximately 80% of India’s $ billion software industry was focus to support US business. Some experts think India’s exports might exceed $100 billion by as early as 2010. Two key factors that might influence the success of India in software are: the support of the Indian government in easing tariffs and restrictions and the low cost of software development in India. Indian programmers are making significantly less than U.S Programmers. However, I believe that in the long term, the cost of software development in India will continue to rise when more works are outsourced there. If Indian software industry does not focus on improving the quality of its products and services, but continue to rely on their low cost labor, India may not enjoy the position as the key software supplier to the world any longer.
I strongly believe software leaders in the next decade will be those who could deliver high quality software within a reasonably cost.
Question: Why wasting time improving software when we can buy rather than build? Why wasting time improving management practices when we can outsource to other countries and reduce cost?
Answer: Not everything we need can be bought in the open market. If reducing cost is important to you then software improvement provides significant opportunities to reduce cost and improve quality. Software is an amazing technology that has zero manufacturing cost, can be distributed worldwide in seconds, does not deteriorate, and it is a very big business today (i.e. look at Microsoft and Google)
Not everything we do can be outsourced to other countries. If reducing cost is important to you then improving people practices provides significant opportunities to increase productivity and reduce cost. Although, the old way of hiring people when you need them and firing people when you do not need them may be in some management mind but the world has changed around them. Today the best talent is going into organization where people are treated with respect for their talents. People will work where they are being appreciated for their contribution and where they are being technically challenged. If getting rid of people by outsourcing is the only way of reducing cost then you are in for a surprise. There is a new trend going on now, companies are throwing the old way of treating people as “commodities” out and creating new way where attracting and retaining talents are the “key assets” in the digital age.
Question: If it takes many years to achieve high CMMI levels and reap the benefit such as reducing cost why don’t we outsource software which is faster and easier?
Answer: Reducing cost is a relative, not an absolute concept. Yes, it sounds so easy to cut cost through outsourcing (i.e. cheaper labors) but outsourcing can only be effective when the organization understands its software requirements and can manage its subcontracts well. If the organization has difficult time managing requirements, control changes, or can not manage its own projects then how does it manages subcontractors half way around the world where language and culture are difference from us? Outsourcing requires significant new skills to manage subcontractors that may include major restructuring of the existing infrastructure for outsourcing to be effective. I believe outsourcing is neither faster, cheaper or easier than in house development and we must consider the issue of cost saving in outsourcing very carefully.
Question: What is Six-Sigma quality and how does it relate to CMMI?
Answer: By definition, to achieve Six Sigma quality, a process must produce no more than 3.4 defects per million opportunities. There is lot of “hype” on Six Sigma but very few organizations have really achieved this kind of near perfect quality. The word “Sigma” is a statistical term that measures how far a given process deviates from perfection. If you can measures how many defects you have in your process, then you can figure how to eliminate them and get close to “Zero defects” as possible.
I believe Six Sigma is a vision that we should strive forward when implements CMMI. To achieve Six Sigma, organization must be data-driven and measurement focuses. The key is reducing process variation, which is very similar to the ordering of CMM levels. From my own experience, organization at level 4 really understand quality attributes, can deliver what customer wants, understand their process capability and managing them by facts and data. Level 5 is where the process optimization occurs to enable the delivery of Six Sigma results.
Question: Why do you advocate improvement at the organization level rather at company level? Would it be easier to do it at higher level?
Answer: How do you change your behavior? How do you expect hundreds or thousands people to change their behavior? Improvement involves culture, behavior, commitment and many more. Improvement is driven by organization goals, domain, skills, and experiences. Since each organization is unique in these characteristics, there are many ways to implement improvement. An organization whose goal is improving time to market may take different approach than organization whose goal is defect free software product. Improvement is also defined by domain; an embedded environment where quality is critical may approach improvement different than a Web environment where speed is critical. Experience and skills also play very important roles in improving organization process. A highly experienced team approach change based on what works and what do not work. An inexperience team may rely on their technical lead or SEPG members to guide them.
To make improvement a success, each organization must understand its process, products, domain and goals before it can select a set of practices to improve its process. There is no set of “improvement miracle” or a “Instant canned solution” like Instant noodle that you can apply universally to every organization and expect real improvement at higher level.
Question: What is the different between Staged versus Continuous model?
Answer: There are many approaches to implement process improvement and there are several modeling techniques. Let us look at the controversy between Staged versus Continuous:
1) Staged models include an explicit improvement path, from one level to another that clearly identifies improvement priorities. Continuous models do not contain an explicit improvement path (There are no explicit levels but everything is continuous)
3) Staged models assist organizations in setting up the necessary infrastructure and developing capability in a manageable manner. It help builds an organizational culture that is consistent with producing the highest quality possible. Continuous model’s primary focus is on changes in process elements, not cultural or organizational change.
4) Staged models focus on the vital few issues that an organization should address based on its capability because an organization can only successfully address a limited number of issues at any one time. Continuous models do not necessarily focus on limited number of key issues but allow the organization to pick and choose whatever issues they want to work on.
5) Staged models represent a shared vision and consensus views of the important issues and the steps an organization should take in their process improvement efforts. Continuous models do not contain this consensus view and shared vision.
6) The maturity level concept in a staged model has five clearly defined levels, which is something management can easily understand and relate to; therefore, it is not that difficult to get their attention and commitment to undertake a process improvement effort. (Definitely, there are pitfalls to an overemphasis on attaining a maturity level.) It is not as easy to get the necessary management commitment to implement a process improvement effort based on a continuous model with no levels.
7) In a staged model, level 2 provides the project management foundation in order for organization standardization can occurs later at level 3. Level 3 also serve as the foundation of well-defined process so that level 4 can focus on establishing a quantitative understanding and control of both the processes being used and the products being built. At level 5, the organization can implement continuous and measurable process improvement. In a continuous model, there is no level since it breaks down all orders and priorities by allowing individual process elements to be improved continuously.
Question: How does usability engineering fit into CMMI or doesn’t it?
Answer: I believe usability is a quality in use. It reflects how easy the software is to learn and use, how productively users will be able to work, and how much support users will need. It is from the user’s view on software quality.
The CMMI is a framework to improve software quality. It is a roadmap to build quality software from project management (Level 2) to product management (Level 3) then to process management (Level 4) and ultimately quality management (Level 5). It is from the developer’s view on software quality.
Usability is difficult attribute to build into any software system since many developers do not realize that their perception of creation does not provide information about how users will react to it. CMMI does address usability issues in Requirements management (level 2), Software Product Engineering (level 3), Software Quality Management (level 4).
Question: Despite being at CMMI level 3 since 2005, our organization is still having problem in reporting project performance. We did have a core set of software measures (Size, effort, schedule and defects) but they are not being used effectively. There are so many errors in compiling them at higher level which resulting in our failures to meet business objectives. We are constantly behind schedule and having budget overrun. Last year, we did not achieve customer satisfaction. Our level 4 efforts do not go very smoothly and the SEPG budget is severely cut. How do we restart?
Answer: Since your organization was assessed in 2005, how do you know that your organization is still at level 3? Do you have any reassessment lately? Typically, an assessment result is only valid for a period of time (1-2 years) and organization must re-assess every 16-24 months. Based on your information that the organization already has a core set of software measures at project level (level 2) but having problem at organization level, i.e. collecting, compiling, reporting, managing, I would be very skeptical about the level 3 achievement.
Forget the level 4 efforts or the SEPG budget cut. You need to re-examine the entire commitment process to find out the root cause. If the goal of your organization is only get a “meaningless level” and not serious about achieve business goals such as customer satisfaction, budget control and schedule commitment then I think your process improvement is in deep trouble.
