Những bài học từ một dự án phần mềm

Trong những dự án phức tạp, đòi hỏi có sự giao tiếp chặt chẽ, chính xác giữa nhóm cung cấp thông tin về sản xuất, dịch vụ với nhóm làm ra phần mềm, thường sẽ có một nhóm trung gian gọi l

nghệ Thông tin của doanh nghiệp (CIO – Chief Information Technology Officer), Quản trị Dự

án (Project Manager) và Kiến trúc sư phần mềm (Software Architect), và sẽ phân tích qua các khía cạnh sau đây của dự án: Quy trình Quản lý (Management Process), Quy trình phát triển phần mềm (Software Development Process) và Kiến trúc phần mềm (Software

Architecture)

Giới thiệu tổng quát về dự án và tổ chức nhân sự

_

Dự án này là một dự án xây dựng một hệ thống enterprise software nhằm mục đích phối hợp

(collaborate) hoạt động giữa các bộ phận trong hệ thống sản xuất giày dép (Footwear

Production) của công ty N trên khắp thế giới, bao gồm:

• Hệ thống quản lý tài liệu Thiết kế giày dép (Footwear production documents), bao

gồm tài liệu, bản vẽ mẫu giày dép, tài liệu về nguyên vật liệu, màu sắc, công nghệ …

• Hệ thống quản lý dự án sản xuất (Project Management) để quản lý các dự án cho từng

mẫu giày dép, từ thiết kế qua tới thử nghiệm, sản xuất, tiêu thụ …

• Hệ thống phối hợp hoạt động giữa các bộ phận khác nhau của công ty N, từ Bộ phận Thiết kế mẫu sản phẩm ở Bắc Mỹ đến các Nhà máy sản xuất giày dép đặt tại châu Á

và các Nhà cung cấp nguyên vật liệu trên khắp thế giới

Bao gồm việc lưu chuyển và quản lý một cách tự động việc đưa mẫu thiết kế từ Bắc

Mỹ đến sản xuất thử nghiệm tại châu Á, đến việc thử nghiệm, thu thập thông tin về sản phẩm mẫu, cải tiến, sản xuất chính thức và tiêu thụ, tự động theo dõi hệ thống lưu chuyển nguyên vật liệu và vận tải sản phẩm

Trước đây, công ty đã có thời kỳ sử dụng mainframe computer và COBOL, sau đó tới thời kỳ

sử dụng Power Builder và SAP để quản lý một số phần rất nhỏ trong quy trình sản xuất Hiện

nay, công ty muốn xây dựng một hệ thống hoàn chỉnh, toàn diện với những công nghệ mới hiện nay

Công nghệ được sử dụng trong dự án là J2EE và Oracle database Application Server

là Apache Webserverkết nối với Tomcat servletengine Dự án này không phải được xây dựng

hoàn toàn từ đầu (build from scratch), mà dựa trên một enterprise platform khá nổi tiếng

trong loại phần mềm PDM/PLM (Product Data Management/Product Lifecycle

Management) và Enterprise Collaboration Software, có tên là Windchill Windchill là một

sản phẩm J2EE của công ty PTC (Parametric Technology Corp.), trụ sở chính tại bang Massachusetts, Mỹ [1] Đây là một phần mềm nền tảng (platform), cung cấp toàn bộ cơ sở hạ

tầng và các chức năng căn bản cho một hệ thống enterprise software

Các công ty sản xuất có nhu cầu xây dựng B2B enterprise software để phối hợp hoạt động

giữa các bộ phận khác nhau trong công ty, hoặc với các công ty khác, với các nhà cung cấp

và khách hàng thường sẽ ít khi xây dựng từ đầu, mà sẽ mua Windchill (hoặc các sản phẩm tương tự, ví dụ như Matrix One, EDS, SAP, People Soft, IBM Dassault …) về, cải biến và

cài đặt thêm (customization) trên platform có sẵn để phù hợp với đặc điểm riêng của doanh

nghiệp, và đưa vào sử dụng Hiện có khoảng hơn 3000 công ty sản xuất lớn trên thế giới đang

sử dụng Windchill để điều hành hoạt động của toàn bộ doanh nghiệp, trong đó có nhiều tên tuổi đáng kể như NASA, Boeing, Airbus, Lockheed Martin, Rolls Royce, DaimlerChrysler, Ferrari, Toyota, Bose … Mỗi dự án triển khai Windchill cho một doanh nghiệp kéo dài vào khoảng từ 6 tháng đến 2 năm (Một thời gian tương đối ngắn cho việc triển khai Enterprise Software, bao gồm cài đặt hệ thống, cải biến và cài đặt thêm, performance tuning,

administrator training, user training, chạy thử nghiệm và chạy chính thức).[2]

Từ 4 năm nay, Công ty sản xuất hàng thể thao N cố gắng dử dụng Windchill làm nền cho hệ thống enterprise software của mình, và đã chi hơn 35 triệu USD cùng nhiều nhân tài vật lực vào dự án này

Bộ phận Sản xuất giày dép (Footwear Production) của công ty N có bộ phận IT riêng của

mình, nhưng để triển khai dự án, công ty thuê các chuyên gia tư vấn về Công nghệ thông tin

để tiến hành Đây là cách làm việc rất phổ biến ở Mỹ, vì việc phát triển phần mềm hoặc cài đặt các hệ thống mới chỉ mang tính chất thời vụ, nhưng lại đòi hỏi trình độ chuyên môn cao Mặt khác, khi hệ thống đã hoàn thành, thì việc vận hành và bảo trì chỉ đòi hỏi trình độ chuyên môn tương đối thấp Vì thế các công ty sản xuất và dịch vụ chỉ duy trì một đội ngũ IT với trình độ vừa phải, lương thấp để bảo trì và vận hành hệ thống, và khi có nhu cầu làm mới, thì

sẽ thuê chuyên viên tư vấn với giá cao, nhưng chỉ trong thời gian thực hiện dự án Cách làm này giúp cho công ty tiết kiệm chi phí hoạt động, và bảo đảm tính chuyên môn hóa cao (Giả

sử là công ty thuê được chuyên gia tư vấn tốt, và tổ chức làm việc theo nhóm một cách có hiệu quả)

Trong quản lý dự án, công ty N sử dụng một Quản trị dự án (Project Manager) là nhân viên chính thức của N (Permannent full time employee) Các nhân viên trong Dự án được chia làm

ba nhóm chính là Nhóm Chuyên gia sản xuất giày dép (Domain expert – Trong trường hợp

này, domain là footwear production, và nhóm còn gọi là Footwear Expert), Nhóm Phân tích

Hệ thống kinh doanh (Business System Analyst) và Nhóm Chuyên gia phần

mềm (Application Engineer)

Nhóm Chuyên gia sản xuất giày dép là những nhân viên chính thức của công ty N, công việc hàng ngày là thiết kế mẫu giày dép, giao dịch với các nhà máy ở châu Á và công ty cung cấp nguyên vật liệu trên khắp thế giới, là những người sẽ cung cấp thông tin về quy trình, phương pháp và logic làm việc của công việc footwear production cho Dự án

Nhóm Chuyên gia Phần mềm (Application Engineer) có nhiệm vụ dựa trên những thông tin

về quy trình, phương pháp và logic làm việc để xây dựng phần mềm tự động hóa những công việc đó Trong nhóm này, các vị trí Senior đều là các chuyên viên tư vấn, và ở những vị trí lập trình, có xen lẫn những nhân viên tư vấn có kinh nghiệm và nhân viên chính thức của N Trong những dự án phức tạp, đòi hỏi có sự giao tiếp chặt chẽ, chính xác giữa nhóm cung cấp thông tin về sản xuất, dịch vụ với nhóm làm ra phần mềm, thường sẽ có một nhóm trung gian gọi là Nhóm Phân tích Hệ thống sản xuất (Business System Analyst), đóng vai trò trao đổi thông tin giữa Nhóm Domain Expert và Nhóm Application Engineer

Trong Công nghệ Phần mềm, thông thường những chuyên gia sản xuất, dịch vụ và những Chuyên gia Phần mềm nhìn công việc và hệ thống từ những góc nhìn khác nhau, và sử dụng những thứ ngôn ngữ khác nhau để mô tả về hệ thống Do đó, những chuyên gia trong nhóm Phân tích Hệ thống sản xuất phải vừa có kiến thức về sản xuất lẫn kiến thức về làm phần mềm (về độ am hiểu chuyên môn sâu thì không cần thiết phải như các nhóm Chuyên gia Sản xuất và Chuyên gia Phần mềm, nhưng phải am hiểu các khái niệm cơ bản và thuật ngữ) để có thể làm trung gian giữa hai nhóm Trong nhóm Phân tích Hệ thống sản xuất có cả chuyên viên tư vấn lẫn nhân viên chính thức của công ty N

Điểm yếu nhất trong ba nhóm của công ty N là Nhóm Phân tích Hệ thống sản xuất Nhóm này (hoàn toàn trái ngược với yêu cầu) không có một khái niệm gì cả về sản xuất giày lẫn về sản xuất phần mềm Điều này làm nảy sinh ra tình trạng hoạt động không hiệu quả trong quy trình quản lý và quy trình làm phần mềm

Những điểm yếu trong quy trình quản lý

(Management Process)

_

Công ty N không có một phương pháp chuẩn (methodology) nào trong việc quản lý dự án

phần mềm Dựa trên quá trình thu thập thông tin, chưa xây dựng thành Use Case, chưa qua

phân tích và làm specification, mới chỉ dựa trên một vài mục đích, nhận định, công ty đã đưa

ra một số giới hạn về thời gian, nhân lực, ngân sách, mà không có căn cứ cụ thể

Về mặt quản lý, công ty hoàn toàn không có phương pháp cụ thể về việc phân chia trách nhiệm, quyền hạn giữa các nhóm và các thành viên trong các nhóm Điều này dẫn đến tình trạng có những lúc công việc bị ách tắc hoặc sai lệch, nhưng không tìm được nguyên nhân chính một cách kịp thời, và không quy được trách nhiệm cho đối tượng nào cần phải sửa chữa hoặc có hình thức xử lý

Công ty cũng hoàn toàn không có một hệ thống hợp lý để theo dõi quá trình làm việc, theo dõi về ngân sách và tiến độ để có thể điều chỉnh cho phù hợp Điều này dẫn đến các giai đoạn

của dự án thường xuyên bị chậmdead line và vượt quá ngân sách dự tính

Do không có Phương pháp chính thức (formal methodology) để đánh giá về khả năng, trình

độ cũng như tốc độ làm việc của từng nhóm và từng nhân viên trong dự án, và do không có

đủ trình độ về Chuyên môn Sản xuất giày dép và Chuyên môn về Công nghệ Phần mềm để

có thể nhận định được về năng lực và kết quả làm việc thực sự của nhân viên, nên Quản trị

Dự án (Project Manager) và Ban Lãnh đạo Dự án thu thập thông tin bằng cách nói chuyện

với nhân viên này trong dự án để tìm hiểu về nhân viên kia, họp với nhóm này để lấy thông tin về nhóm kia trong dự án, và dẫn đến những đánh giá chủ quan, cảm tính và thường không chính xác Sự đời ở đâu cũng thế, những kẻ nói giỏi và những kẻ hay nói thường là làm ăn không ra gì, và thông tin thường là sai lệch Vì thế Ban Lãnh đạo Dự án hoàn toàn không có một nhận thức chính xác về trình độ nhân viên, tiến trình của dự án, và không nắm bắt được chi tiết những gì đang thực sự xảy ra trong dự án

Công ty N thực hiện khâu tổ chức thực hiện dự án một cách hết sức máy móc Hàng tuần, có những cuộc họp cố định vào thứ hai để báo cáo tiến độ công việc, vào thứ ba để xem xét thiết

kế phần mềm và thứ năm để trao đổi thông tin giữa các nhóm Chuyên gia Sản xuất, Chuyên gia Phân tích Hệ thống Sản xuất và Chuyên gia Phần mềm Ngoài ra còn rất nhiều cuộc họp phụ khác Một tuần làm việc có 40 tiếng, đã có một vài lần tôi phải tham gia họp 30 tiếng một tuần, và có một vài ngày tôi phải ngồi 6 tiếng trong phòng họp

Mặc dù có cuộc họp để báo cáo tiến độ công việc, nhưng vì thiếu một phương pháp tốt để theo dõi, phân tích, đánh giá tình hình và phân chia trách nhiệm, nên những cuộc họp này chỉ giúp cho Quản trị Dự án nhận ra những gì đã làm được, những gì còn lâu mới xong, mà không biết tại sao, có cách nào làm nhanh hơn không, đâu là vị trí khó khăn tại thời điểm này của dự án…

Cuộc họp về xem xét thiết kế phần mềm cũng không có tác dụng gì bổ ích mấy, vì công ty N

đã tốn 4 năm và chi phí hơn 35 triệu USD để xây dựng một hệ thống phần mềm có nhiều vấn

đề về mặt thiết kế (tôi sẽ phân tích kỹ hơn trong phần liên quan tới Kiến trúc phần mềm) Đại khái cũng như trong xây dựng, khi người ta đã vẽ ra một thiết kế có vấn đề và xây nên một vài phần móng có vấn đề, thì việc xây thêm và gia cố cũng khómà dẫn đến một kiến trúc gì thực sự tốt và có giá trị sử dụng được Vì thế, các cuộc họp này chỉ nhằm đưa ra những giải pháp chắp vá, tạm thời để tạo ra những chức năng có liệt kê trong danh sách mục đích xây dựng phần mềm

Nhưng những cuộc họp về trao đổi thông tin giữa các nhóm làm việc mới thực sự là thảm họa Có một quy định hết sức máy móc là Nhóm Chuyên gia Sản xuất chỉ được nói chuyện với Nhóm Phân tích Hệ thống sản xuất, rồi nhóm này sẽ đi nói lại với Nhóm Chuyên gia Phần mềm Nhóm Chuyên gia Phần mềm cần hỏi thông tin gì, cũng chỉ được phép nói

chuyện với Nhóm Chuyên gia Phân tích, rồi nhóm này sẽ đi hỏi Nhóm Chuyên gia Sản xuất

và truyền đạt lại

Trong khi đó, như đã nói, Nhóm Chuyên gia Phân tích lại bao gồm những người không có khái niệm gì về cả Sản xuất giày lẫn Sản xuất Phần mềm, nên Nhóm Phân tích chỉ đóng vai trò như Nhóm đưa tin giữa hai nhóm Chuyên gia Sản xuất và Chuyên gia Phần mềm Hơn nữa, do không có trình độ chuyên môn, nên nhóm Phân tích không đọc được Use Case

Diagram để trao đổi với nhóm Phần mềm, mà cũng không biết các thuật ngữnhư size-range, color-bucket … để nói chuyện với nhóm Sản xuất

Như vậy, hoàn toàn không có một thứ ngôn ngữ chính xác để trao đổi về mặt phân tích yêu cầu, thu thập thông tin và thiết kế hệ thống cho toàn bộ dự án Ngoài ra, cách tổ chức trao đổi thông tin cũng kỳ quặc: Trong thứ năm của một tuần, Nhóm Phần mềm họp với Nhóm Phân tích, bàn đi bàn lại một hồi, rút ra là có một số vấn đề sau đây chúng ta chưa biết Nhóm Phân tích sẽ đem vấn đề đó đi hỏi nhóm Sản xuất vào cuộc họp thứ năm tuần kế tiếp Và trong cuộc họp ngày thứ năm của tuần tiếp sau nữa, Nhóm Phân tích sẽ đem câu trả lời về cho Nhóm Phần mềm Như vậy là mất 3 tuần cho một câu hỏi và trả lời, và việc này diễn ra trong

4 năm nay, mặc dù đi bộ từ khu nhà của Nhóm Phần mềm xuống Nhóm Sản xuất mất đúng 3 phút, và tất cả các nhân viên trong dự án đều có điện thoại và e-mail Đó là chưa kể đến sự thiếu hiểu biết chuyên môn của Nhóm Phân tích dẫn đến việc trình bày sai, thiếu phương

pháp ghi chép tài liệu (documentation methodology), nên có những vấn đề phải hỏi đi hỏi lại

Có hai trường hợp điển hình Một lần có một chuyên gia phần mềm hỏi “Trong thiết kế mẫu, người ta quản lý cỡ giày như thế nào, theo giá trị chính xác (exact size, nghĩa là từng con số 5,6,7,8,9 ), hay theo khoảng cỡ (size-range, tức là 5-7, 8-10 , 11-12 …) Sau vài tuần trao đổi đi, trao đổi lại, Nhóm Phân tích không đưa ra được câu trả lời cụ thể Chuyên gia phần mềm đành phải làm một câu hỏi có nhiều chọn lựa (multi-choice question), gồm có a) Quản

lý theo giá trị chính xác, b) Quản lý theo khoảng cỡ, c) Quản lý theo kiểu khác, đề nghị viết

rõ, rồi đưa cho Nhóm Phân tích đi hỏi Nhóm Sản xuất, đề nghị khoanh vào a hoặc b hoặc c, thì mới có câu trả lời là a)

Nếu không có quy định quá máy móc là Nhóm Phần mềm không được giao tiếp với Nhóm Sản xuất , hoặc nếu Nhóm Phân tích biết chuyên môn cơ bản và biết sử dụng thuật ngữ, thì tình trạng không đến nỗi thế

Trường hợp thứ hai là có lần có chuyên gia phần mềm hỏi: “Về mặt quản lý vận tải, trong một lần gửi hàng, có thể có hàng hóa của nhiều đơn đặt hàng được gửi cùng một chuyến hay không?”

Trước đây công ty N không có hệ thống theo dõi vận tải, mọi giao dịch được làm bằng giấy

tờ Thay vì đi hỏi trực tiếp những người từ trước đến nay vẫn theo dõi việc vận tải bằng sổ sách, Ban Quản trị Dự án họp nhau đoán già đoán non, và cho rằng việc theo dõi nhiều đơn đặt hàng khác nhau trong một chuyến vận tải là quá khó (?), nên cho rằng phần mềm chỉ cần theo dõi mỗi chuyến vận tải là một đơn đặt hàng thôi, bất chấp ý kiếncủa Nhóm Phần mềm là

về mặt công nghệ không có gì khó, và ý kiến của Nhóm Sản xuất là trước nay vẫn có nhiều

trường hợp một chuyến hàng chứa nhiều đơn đặt hàng Sau khi Nhóm Phần mềm cài đặt xong Hệ thống theo dõi Đơn đặt hàng và Vận tải, công ty N cử một nhóm 3 người sang châu

Á để đưa cho các nhà máy ở châu Á sử dụng thử và thu thập ý kiến phản hồi, thì mới nhận ra

là phải làm hệ thống theo dõi nhiều đơn đặt hàng khác nhau trong một chuyến vận tải Kết quả là toàn bộ công việc trong hai tháng trời phải bỏ đi hoàn toàn, làm lại từ đầu

Một hiện tượng khác điển hình cho sự thiếu cả Kiến thức lý thuyết lẫn Kinh nghiệm thực tế trong Quản lý Dự án phần mềm của Ban Lãnh đạo Dự án là mỗi khi dự án chậm so với thời hạn, Ban Lãnh đạo Dự án lại thuê thêm lập trình viên vào, nhằm cứu vãn tiến độ công việc Bất kỳ một nhân viên quản trị dự án phần mềm nào khi mới tập tọng vào nghề cũng phải

nghe qua định luật Brooks [3]:

“Thêm người vào một Dự án phần mềm bị chậm thì chỉ làm cho nó chậm hơn.” Định luật này được Brooks chứng minh bằng mô hình toán học một cách chính xác, và đã được kiểm nghiệm qua rất nhiều dự án phần mềm trong thực tế

Những điểm yếu trong quy trình phát triển phần mềm

(Software Development Process)

_

Công ty N sử dụng một Quy trình Phát triển phần mềm chuẩn trong Công nghệ Phần mềm

là Rational Unified Process (RUP) Hiện tại, trong ngành Công nghệ Phần mềm, đại đa số

các Dự án Phần mềm lớn và phức tạp đều sử dụng RUP làm Quy trình Phát triển phần mềm

Quy trình này gồm có 4 giai đoạn: Khởi đầu (Inception), Dự thảo chi tiết (Elaboration), Thực hiện xây dựng (Construction), Chuyển giao (Transition)

Trình bày chi tiết về Rational Unified Process hoàn toàn không nằm trong khuôn khổ của bài viết này

Nhưng một quy trình tốt không bảo đảm cho sự thành công của một dự án phần mềm

Phương pháp tiến hành các bước trong các giai đoạn của một dự án là một yếu tố hết sức quan trọng Trong toàn bộ ba giai đoạn đầu của dự án, công ty N đều phạm phải các sai lầm hết sức cơ bản Giai đoạn bốn (Transition) chưa bao giờ có, vì chưa bao giờ có sản phẩm chính thức đưa vào sử dụng, nên chưa có sai lầm Suốt 4 năm từ lúc bắt đầu Dự án cho đến nay, sau khi tiêu tốn hơn 35 triệu USD, công ty N mới đưa ra được một vài kết quả thử nghiệm:

• Hệ thống Quản lý Vật liệu (Material Management) Nghe tên thì như vậy, nhưng thực

chất đây là một hệ thống cho phép ghi đối tượng về vật liệu vào database, thêm, xóa, sửa, tìm kiếm …, nghĩa là các chức năng thông thường của một chương trình quản lý

cơ bản bất kỳ cái gì

• Hệ thống Quản lý màu sắc (Color Management) : Đây là một hệ thống cho phép

thêm, xóa, sửa, tìm kiếm màu sắc trong database

• Hệ thống quản lý Dự án (Project Management), thực ra chỉ là một hệ thống tạo thêm, xóa, sửa, tìm kiếm tài liệu cho các dự án, chứ không có quản lý tiến trình (workflow management) và theo dõi tiến độ dự án (project progress tracking), đang trong giai

đoạn chạy thử nghiệm và có đầy lỗi

* Giai đoạn Khởi đầu (Inception) :

Đây là giai đoạn dùng để thu thập thông tin, nhằm đặt ra mục đích và tầm mức của Dự án Phần mềm Thay vì thu thập trực tiếp thông tin trong thực thế thiết kế và sản xuất giày để xây dựng tầm mức và mục đích, công ty N đã chọn cách thu thập chức năng và mục đích cho chương trình bằng cách sao chép lại toàn bộ chức năng và mục đích của hệ thống phần mềm

cũ (legacy system) chạy trên mainframe, hệ thống cũ làm bằng Power Builder và SAP Đây là

một sai lầm hết sức ấu trĩ, vì các legacy system kể trên được xây dựng cách đây hàng chục năm, dựa trên công nghệ hết sức lạc hậu, không thông qua các quy trình thiết kế và phân tích

chuẩn cho các hệ thống Hướng đối tượng (Object Oriented), vì thời đó chưa có công nghệ

này

Hơn nữa, quy trình thiết kế và sản xuất giày dép và việc trao đổi thông tin hiện nay đã khác

xa so với quy trình hàng chục năm trước, công nghệ sản xuất, phương tiện sản xuất, phương tiện thông tin liên lạc giữa các chi nhánh và quy trình sản xuất đã hoàn toàn thay đổi Chính

vì thế, quyết định về việc xây dựng một hệ thống phần mềm với công nghệ mới để sao chép hoàn toàn chức năng và hoạt động của hệ thống phần mềm cũ đang sẵn có, với rất ít bổ sung,

là rất phi lý, thiếu thực tế, và xét cho cùng, nếu vậy thì cứ việc giữ nguyên hệ thống cũ để sử dụng thì còn có giá trị thực tiễn và kinh tế cao hơn

* Giai đoạn Dự thảo chi tiết (Elaboration):

Trong giai đoạn này, các thông tin thu thập được ở giai đoạn Khởi đầu (Inception) sẽ được

đánh giá và phân tích chi tiết, nhằm xác định cụ thể, chính thức về tầm mức của dự án

(project’s scope) , các yêu cầu của dự án (project’s requirement), các điều kiện để dự án được coi là hoàn thành (project’s acceptance criteria), các tính năng của dự án (project’s feature) và những tính năng nào là quan trọng (critical criteria), xác định những mạo hiểm có thể xảy ra (potential risk), xác định chi tiết về thực tế sản xuất (business specification) để dẫn tới xây dựng chi tiết về thiết kế phần mềm (design specification) và xây dựng dự thảo cho kiến trúc phần mềm (software architecture) Những công việc hỗ trợ như thiết lập mạng (network), mua bán phần cứng (hardware), phần mềm (software), chuẩn bị quy trình, công cụ

cũng được thực hiện trong giai đoạn này

Một trong những sai lầm căn bản nhất của giai đoạn cụ thể hóa dự án này là Ban Lãnh đạo

Dự án đã đánh giá sai thời gian và khối lượng công việc trong việc chuyển đổi database từ

các hệ thống cũ (legacy system) dùng mainframe, Power Builder và SAP sang Oracle

database của Windchill

Không hiểu căn cứ vào đâu, dựa trên những tiêu chí nào, vào những phân tích ra sao, mà Ban Lãnh đạo Dự án xác định rằng để chuyển đổi database từ hệ thống cũ sang Windchill’s Oracle database phải tốn ít nhất là 5 năm Điều này chứng tỏ Ban Lãnh đạo Dự án không có bất kỳ một khái niệm gì về database migration

Hệ thống cũ chạy Power Builder và SAP cũng dùng Oracle database, nghĩa là hoàn toàn có thể được truy cập từ chương trình Java Có những dữ liệu được lưu trong những khu vực lưu

trữ riêng của Power Builder App và SAP, nhưng đều có những công cụ kết nối (adapter), do

đó có thể đọc được từ chương trình Java

Như vậy công việc chuyển đổi database từ legacy system sang Windchill bao gồm những phần việc sau:

1 Xác định database schema và data format của legacy system

2 Xây dựng database schema cho hệ thống mới trong Windchill’s Oracle database

3 Viết một chương trình đọc database từ legacy system và ghi vào Windchill’s

database

Đây là một công việc rất cơ bản, hầu như là lặp đi lặp lại cho tất cả các dự án có chuyển đổi

database (database migration) Bất kỳ một Kiến trúc sư Phần mềm (Software Achitect) có

kinh nghiệm nào cùng với một nhóm lập trình viên trình độ trung bình có thể hoàn thành những Dự án database migration trong khoảng 6 tháng đến 1 năm Rất nhiều dự án database migration ở những nhà máy sản xuất máy bay chiến đấu, tàu ngầm hạt nhân, ô tô đua … (là những thứ phức tạp hơn một chiếc giày rất nhiều) được thực hiện với thời gian còn ngắn hơn thế

Chính vì nhận định sai về thời gian chuyển đổi database, nên Ban Lãnh đạo Dự án đã đề ra một mục đích và tầm mức hết sức kỳ quặc cho dự án

Dự án sẽ được xây dựng như là một chương trình sử dụng Java, J2EE trên nền Windchill để cung cấp giao diện mới và database mới cho một Hệ thống quản lý sản xuất giày có chức năng giống hệt như Hệ thống cũ viết bằng Power Builder, với một vài chức năng mới không đáng kể, ví dụ như theo dõi Vận tải và Đơn đặt hàng Phần phối hợp chức năng hoạt động giữa các bộ phận, tạo ra một vài loại đối tượng nhất định, vẫn dùng Hệ thống cũ viết bằng Power Builder và SAP, rồi gửi dữ liệu qua Windchill Dần dần, sau một thời gian chạy thử vào khoảng 7 đến 10 năm, một hệ thống mới được xây dựng dựa trên Windchill sẽ được đưa vào thay thế hoàn toàn hệ thống cũ

Sự sai lầm của nhận định về mục đích và tầm mức này là: Windchill đã có sẵn toàn bộ các chức năng để phối hợp hoạt động sản xuất và kinh doanh giữa các bộ phận khác nhau (vì thế nên nó mới được gọi là PDM/PLM và Collaborative enterprise software) Quyết định chỉ dùng Windchill để làm giao diện và lưu trữ dữ liệu, trong khi đó vẫn dùng hệ thống cũ để

phối hợp hoạt động (mặc dù công nghệ của hệ thống cũ đã lạc hậu, lỗi thời và không có đủ chức năng) là một quyết định không thể hiểu nổi

Hơn nữa, theo tiến trình phát triển của công nghệ hiện nay, trong khoảng 7 đến 10 năm nữa, công nghệ đã hoàn toàn thay đổi, những Hệ thống được xây dựng dựa trên J2EE hiện tại sẽ trở nên lỗi thời Chả lẽ lúc đó lại tiến hành xây dựng một hệ thống mới, trong lúc việc chuyển đổi chức năng, dữ liệu giữa Hệ thống Power Builder + SAP với Hệ thống Windchill hiện nay chưa xong, và sử dụng song song cả 3 hệ thống cho tới 7 hay 10 năm tiếp sau đó nữa?

Những nhận định và kế hoạch nói trên chứng tỏ Ban Lãnh đạo Dự án thiếu thực tế về mặt Sản xuất và không có khái niệm gì về Quản lý và Tiến hành Dự án Phần mềm

Khâu chuẩn bị vật chất và công cụ cho dự án cũng được tiến hành rất kém Mạng máy tính của công ty N vào năm 1999 đã bị hacker tấn công một lần, tai tiếng khá lớn, nên công ty trở

nên quá đa nghi về an ninh mạng (network security), và do thiếu khả năng, nên đã cài đặt quá

nhiều công cụ security tự động lên mạng và các máy tính cá nhân, làm cho mạng máy tính trở nên chậm và kém ổn định Rất nhiều lập trình viên trong một ngày đẹp trời tự nhiên thấy máy tính của mình bị loại khỏi domain của N network, và phải gọi quản trị mạng để kết nối trở lại Máy tính được dùng trong hệ thống được mua của một hãng khá danh tiếng, nhưng có lẽ là loại rẻ, dùng cho gia đình, chưa qua test để dùng trong công nghiệp, nên có rất nhiều máy tính bị hỏng, nguy hiểm nhất là hỏng đĩa cứng, và mất toàn bộ dữ liệu

Về môi trường phát triển phần mềm (software development environment), công ty sử dụng khá nhiều công cụ chuẩn (standard tool) được sử dụng rộng rãi trong Công nghệ Phần mềm ở

nhiều công ty khác, nhưng đáng tiếc là lại sử dụng sai, nên phát sinh rất nhiều sự cố trong quá

trình phát triển phần mềm Một ví dụ điển hình là để kiểm soát mã nguồn (source code

control) và chia sẻ làm việc theo nhóm, công ty sử dụng ClearCase, một công cụ quản lý mã

nguồn rất mạnh của công ty Rational Software Nhưng đáng tiếc là công ty không thuê đúng chuyên gia cài đặt và định cấu hình ClearCase có đủ trình độ, nên việc quản lý mã nguồn của

dự án luôn luôn gặp trục trặc, chương trình không dịch được, hoặc ClearCase view không thể update được là chuyện bình thường

Chương trình dùng để viết Java code trong Dự án là Eclipse, một opensource IDE rất phổ biến, có nhiều chức năng và công cụ rất mạnh, nhưng do mã nguồn của dự án và từng project được tổ chức trên File System quá phức tạp, nên việc setup Eclipse Project để viết và chạy chương trình đòi hỏi phải qua rất nhiều bước phức tap, và không có chuẩn hóa Quá trình tạo

mẫu đối tượng (object modeling), phát sinh mã nguồn Java cho đối tượng (Java source code generation) và phát sinh lệnh SQL để tạo table trong database (SQL generation) được thực hiện bằng UML diagram trong Rational Rose Nhưng do không biết cách cài đặt (setup) và định cấu hình (configure), nên mỗi lần thay đổi mô hình (model), các lập trình viên lại trải

qua một thời gian dài đau khổ trước khi database hoạt động và chương trình chạy trở lại Có nhiều lập trình viên đến công ty chơi cả tuần vì máy tính hỏng, không có gì để làm, và cũng không có máy tính để thay thế Hiện nay, công ty đang thuê một vài nhân viên tư vấn để

chuyên nghiên cứu về việc cài đặt môi trường phát triển (setup development enviroment),

nhưng tình hình cải biến một cách chậm chạp, mặc dù project đã tiến hành được 4 năm

* Giai đoạn Thực hiện xây dựng (Construction):

Trong giai đoạn này, sai lầm có tính chất quyết định chính là sai lầm về Kiến trúc phần mềm

(Software Architecture) Những sai lầm này sẽ được phân tích chi tiết trong phần Những

điểm yếu trong Kiến trúc Phần mềm

Trong phần này, tôi tập trung phân tích những sai lầm của việc cài đặt phần mềm, nhưng không liên quan đến kiến trúc

Ban Lãnh đạo Dự án của công ty N chọn quy trình phát triển phần mềm theo mô hình

Iterative Development, là một mô hình rất phổ biến trong phát triển phần mềm hiện nay Nhưng Ban Lãnh đạo Dự án đã hiểu sai toàn bộ ý nghĩa của Iterative Development

Iterative Development chia quá trình xây dựng phần mềm làm nhiều khoảng thời gian nhỏ

gọi là iteration Trong từng iteration đó, có đủ cả bốn giai đoạn của RUP là Khởi đầu

(Inception), Dự thảo chi tiết (Elaboration), Thực hiện xây dựng (Construction) và Chuyển giao (Transition) Toàn bộ Hệ thống phần mềm sẽ được chia nhỏ thành từng chức năng hoặc

nhóm chức năng, đủ để thực hiện trong thời gian của một iteration Trong khoảng thời gian của một iteration, chức năng (hoặc nhóm chức năng) phải hoàn thành sẽ được đưa qua đủ 4 giai đoạn kể trên, và phân tích, thiết kế cho thành phần phần mềm này của Hệ thống có thể được phát triển, thay đổi hoặc đánh giá lại, và kết quả là khi kết thúc mỗi iteration, sẽ có thêm một phần của Dự án được hoàn thành Trải qua nhiều iteration, cả hệ thống phần mềm

sẽ được hoàn thành Phát triển theo mô hình Iterative Development như thế sẽ cho phép bổ sung thêm thông tin thực tế, thay đổi thiết kế và chỉnh sửa việc cài đặt chức năng cho từng chức năng hoặc nhóm chức năng, mà không làm ảnh hưởng hoặc ảnh hưởng rất ít đến tiến trình của toàn bộ Dự án và các phần khác của Hệ thống

Nhưng các iteration trong Dự án của công ty N được thực hiện như sau: Cả hệ thống được chia làm nhiều chức năng (hoặc nhóm chức năng) nhỏ Sau đó, mặc dù việc phân tích mới chỉ qua loa đại khái, chưa có đủ thông tin đã bắt tay ngay vào việc thiết kế và lập trình Sau khi hoàn thành việc lập trình cho chức năng (hoặc nhóm chức năng) này, bỗng nhiên quá trình thu thập thông tin, phân tích có thêm thông tin, thiết kế thay đổi, thế là lại vứt bỏ toàn bộ từ

mô hình đối tượng (object model), Java code cho đến database schema, viết lại từ đầu trong

một iteration mới Kết quả là trải qua nhiều iteration, sẽ có một phần của Dự án được hoàn

thành, và thời hạn của Dự án (dead line) thường xuyên bị thay đổi, dời chậm lại Ban Lãnh

đạo Dự án thường nhắc đi nhắc lại mỗi khi bắt đầu một iteration mới là “Chúng ta lùi hai bước để tiến lên ba bước”, nhưng trên thực tế là lùi hai bước và chỉ tiến lên đúng hai bước (vì kết thúc iteration mới, cũng chỉ có chức năng trong iteration cũ được cài đặt lại mà thôi), và quá trình này diễn ra lặp đi lặp lại rất nhiều lần

Hiện tượng trên xảy ra vì Ban Lãnh đạo Dự án không hiểu ý nghĩa và cách vận dụng của

Iterative Development, đồng thời Kiến trúc sư Phần mềm (Software Architect) của Dự án không có tầm nhìn đủ xa vàkhông có đủ kỹ năng để thiết kế mẫu đối tượng (object model) và

sử dụng mẫu thiết kế (Design Pattern) một cách tổng quát (generic) và linh hoạt (flexible), để

mỗi khi có thay đổi về yêu cầu và thay đổi thông tin, thì không ảnh hưởng đến kiến trúc của

hệ thống hoặc ảnh hưởng rất ít Kiến trúc Hệ thống của công ty N không đạt được tính ổn định, linh hoạt, dễ bảo trì và dễ sử dụng, vì những người thiết kế Hệ thống và Ban Lãnh đạo

Dự án đơn thuần chỉ có giải pháp tức thời cho những thông tin trước mắt, không có hoạch

định (planning) và tầm nhìn (vision) cho sự thay đổi, mở rộng và phát triển

Một sai lầm khác không thể hiểu nổi của Ban Lãnh đạo Dự án là thứ tự thực hiện cài đặt phần mềm Thông thường, các thông tin thực tế trong sản xuất và dịch vụ sẽ được thu thập, phân tích, đánh giá, hệ thống hóa và được viết lại dưới dạng Use Case và vẽ ra Use Case Diagram Sau khi Use Case và Use Case Diagram được đánh giá là đủ tốt và chính xác vào một thời điểm nhất định của dự án, các lập trình viên sẽ tạo ra các chức năng của chương trình dựa trên Use Case và Use Case Diagram Trong Dự án của công ty N, các thực tế sản xuất, thông tin thực tế được Nhóm Sản xuất nói cho Nhóm Phân tích, và Nhóm Phân tích nói lại cho Nhóm Phần mềm, thông qua các tài liệu viết bằng tiếng Anh, nhưng không có độ chính xác

về thuật ngữ, và các biểu đồ được vẽ một cách tùy tiện với những hình khối tùy tiện, không

có cú pháp (syntax) và ngữ nghĩa (semantic) nào chặt chẽ, và cũng không có một Phương

pháp Chính thức (formal methodology) nào cho việc trao đổi, ghi nhận và trình bày thông tin Nhóm Phần mềm sẽ căn cứ vào những tài liệu này vừa làm, vừa đoán, vừa hỏi, vừa đi họp, sau đó, qua rất nhiều iteration như đã trình bày ở trên, sẽ làm ra một chức năng (hoặc nhóm chức năng) tạm chấp nhận được Trong thời gian Nhóm Phần mềm làm lập trình qua nhiều iteration, thì Nhóm Phân tích sẽ đi hỏi han cả Nhóm Sản xuất lẫn Nhóm Lập trình để xem thông tin thực tế, yêu cầu và phân tích như thế nào, được lập trình ra sao, sau đó bắt đầu viết Use Case bằng tiếng Anh thông thường và vẽ biểu đồ bằng Visio một cách tùy tiện, sử dụng mũi tên, hình khối và tạo bóng thẩm mỹ một cách bừa bãi chứ không sử dụng UML Kết quả

là mỗi khi Nhóm Phần mềm hoàn thành một iteration Lập trình, thì Nhóm Phân tích cũng cho

ra một version của Use Case document nói chung chả ai thèm đọc và chả giúp ích gì cho ai

Có bao nhiêu iteration để lập trình một chức năng thì cũng có bấy nhiêu version của Use Case document, nhưng Use Case được viết ra sau khi đã lập trình xong, không có cú pháp (syntax) và ngữ nghĩa (semantic) chính xác, thì cũng chả có tác dụng gì ngoài việc làm tốn giấy, tốn mực máy in và tốn chỗ lưu trữ trong tủ

Trong quá trình lập trình cụ thể , do Ban Lãnh đạo Dự án và đội ngũ Kiến trúc sư của Dự án quá kém về chuyên môn, nên xảy ra nhiều chuyện hết sức vô lý và làm chậm đáng kể tiến độ lập trình

Một ví dụ điển hình là có trường hợp, một lập trình viên cho server code báo cáo là các đối tượng của anh ta làm việc hoàn toàn chính xác với Unit Test (sử dụng JUnit) và với client sử dụng Struts framework, nhưng thông tin không được hiển thị chính xác trên Swing GUI, trong khi cả JUnit, Struts client và Swing client đều sử dụng server code này theo cùng một

cách, gọi cùng một tập các hàm API và dùng cùng một lớp trung gian (middleware) Qua rất nhiều tuần, Ban Lãnh đạo Dự án cứ nhất quyết đòi lập trình viên này xem xét tại sao server code của mình không hoạt động tốt với Swing GUI Điều này chứng tỏ sự dốt nát toàn diện của Ban Lãnh đạo Dự án và Kiến trúc sư phần mềm (Software Architect) về Lập trình Hướng đối tượng căn bản

Một thành phần phần mềm (software component) hoạt động tốt đối với Unit Test chính là điều chứng tỏ là thành phần này được lập trình đúng theo Chỉ định thiết kế (Design

Specification), và thỏa mãn yêu cầu (Requirement) Một bằng chứng khác về sự hoạt động tốt của server code là thành phần này làm việc chính xác với Struts client Không hiểu do thiếu hiểu biết về lập trình hay vì lý do gì khác, mà Ban Lãnh đạo và Kiến trúc sư phần mềm cứ nhất quyết đòi tìm nguyên nhân không hoạt động trong server code chứ không phải trong Swing GUI code

Những điểm yếu trong Kiến trúc phần mềm

(Software Architecture)

_

Hệ thống phần mềm của công ty N được xây dựng trên nền tảng của Windchill, và sau một

thời gian dài nghiên cứu, Ban Quản trị Dự án đã xây dựng nên một sơ đồ kiến trúc như sau:

Đây là một kiến trúc phần mềm nhiều lớp tiêu biểu (a typical muti-layer software

architecture) Thực ra thì không cần phải là một kiến trúc sư phần mềm giàu kinh nghiệm

mới có thể vẽ được sơ đồ như trên, mà chỉ cần lật một quyển sách Nhập môn Kiến trúc Phần mềm bất kỳ nào cũng có thể thấy những sơ đồ đơn giản kiểu này, thay tên và các mũi tên thích hợp là xong

Việc thiết kế cụ thể và cài đặt cho từng lớp (layer) cũng như tổ chức giao tiếp giữa các lớp

mới là việc quan trọng

Trong Dự án này, toàn bộ tất cả các dịch vụ cho các phần từ Application Layer, Server Layer cho đến Data Layer đã được cài đặt sẵn trong Windchill foundation Trong Kiến trúc

(Architecture) và cài đặt (Implementation) của Windchill foundation đã có cung cấp toàn bộ những thành phần (component) được liệt kê trong sơ đồ như Service Management, Business Services, System Services, Task Delegate, Windchill Adapter Webject, Command Beans, Command Delegate, Info* Engine, Business Object Model, Naming Service, Directory Server , Persistence layer …

Phần cải biến và thêm chức năng chỉ xảy ra trong phần Client Layer và phần xây dựng mô hình cho các đối tượng kinh doanh (Business Object Modelling)

Thực ra trong sơ đồ của phần Server Layer và Data Layer có hai điểm sai rất căn bản, do

Kiến trúc sư Phần mềm (Software Architect) và Lãnh đạo kỹ thuật của Dự án (Technical Lead) trong thời kỳ trước khi tôi tham gia dự án không hiểu rõ về cấu trúc của Windchill,

đoán mò và chép sách Nhập môn Thiết kế phần mềm một cách bừa bãi Thứ nhất là trong

Windchill không có cái gọi là Modelled Attributes (Các thuộc tính được mô hình hóa), vì tất

cả các Business Object đều được mô hình hóa (model) như là những Java Object, và được sử dụng trong tất cả các lớp (layer) từ Windchill Service đến Presentation IBA (International Business Attribute) cũng không phải là một component của kiến trúc phần mềm, mà chỉ là

một hệ thống công cụ để chuyển đổi giữa các hệ thống đo lường Anh-Mỹ và Quốc tế Do đó,

sẽ không có cái gọi là Modelled Attributes và IBA nằm giữa Command Delegate và

Windchill Services Thứ hai là giữa lớp Windchill Services và Oracle Database còn có một lớp nữa là Persistence Layer, làm nhiệm vụ chuyển đổi giữa Java object và Relational

Database (Object-Relational Mapping – ORM), đồng thời đóng vai trò tìm kiếm (query) và thao tác (manipulate) database

Sai lầm căn bản ngay từ xuất phát điểm của dự án là không sử dụng hết các chức năng sẵn có của Windchill Hệ thống Windchill đã cung cấp toàn bộ những tính năng cần thiết của một hệ thống PDM/PLM Enterprise Software bao gồm các chức năng cơ bản như Persistence

Management, Document Magement, Project Management, LifeCycle Management,

Workflow Management, CAD/CAM management, Document and Part versioning, Data Transprotation, Distributed Data Management, Data Replication, Enterprise Security, Access

Control, Enterprise Resource Management and Planning … dưới dạng các dịch vụ (service)

generation from model) và phát sinh SQL DML (SQL Data Manipulation Language)

từ mô hình (SQL DML generation from model), sử dụng Rational Rose

• Sử dụng PersistenceLayer chỉ để ghi object vào database, đọc object từ database và xóa object trong database Không sử dụng được chức năng database query và

database manipulation

• Sử dụng một phần nhỏ của LifeCycle Management để đổi trạng thái (State) của object trong database

• Sử dụng RMI server của Windchill để làm giao tiếp RMI giữa client và server

• Sử dụng Windchill configuration cho Apache Webserver, Tomcat và Aphelion LDAP server để dùng một phần nhỏ của Directory Service và Authentication

Như vậy, các chức năng chính của một enterprise software trong Windchill như object

versioning, data transportation, workflow management, built-in business object , advanced query capabilities, data replication, security và access control hoàn toàn không được sử dụng