You are on page 1of 28

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

Đây là một câu chuyện có thật về một dự án phần mềm trải qua 4 năm và tiêu tốn 35 triệu USD
mà không đem lại kết quả nào, và có kế hoạch kéo dài thêm ít nhất là 4 năm nữa.

Dự án này diễn ra tại một công ty sản xuất dụng cụ thể thao vào hàng đầu trên
thế giới, doanh thu khoảng hơn chục tỷ USD một năm, có trụ sở tại Tây Bắc Mỹ,
tạm gọi là công ty N.

Trên phương diện là một study case, đây là một dự án khá độc đáo, và có thể
dùng làm bài học điển h́nh về nhiều khía cạnh khác nhau của một dự án phần
mềm, nhất là dành cho các doanh nghiệp sản xuất, dịch vụ đang có ư định ứng
dụng công nghệ thông tin vào quy trnh sản xuất và hoạt động của ḿnh. Bài viết
này hướng tới các đối tượng là Giám đốc Công 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 trnh Quản lư (Management Process),
Quy trnh phát triển phần mềm (Software Development Process) và Kiến trúc
phần mềm (Software Architecture).

I. 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 trnh 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 Webserver kết nối với Tomcat servlet engine. 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 ḿ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 ḿ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 trnh độ 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 trnh độ 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 trnh độ 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 P hân t ích H ệ thống kinh d oanh
(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 trnh, 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 trnh, 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 trnh, 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 tṛ 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 ǵ 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 trnh quản lư và quy trnh làm phần mềm.

II. Những điểm yếu trong quy trnh 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á trnh 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á trnh 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ậm dead 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, trnh độ 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ó đủ trnh độ 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 ǵ, 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ề trnh độ nhân viên,
tiến trnh của dự án, và không nắm bắt được chi tiết những ǵ đ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 pḥ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 ǵ đă làm được,
những ǵ 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 ǵ 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 ǵ 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 ǵ, 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 ǵ 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 tṛ 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ó trnh độ 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 trnh 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ến của Nhóm Phần mềm là về mặt công
nghệ không có ǵ 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 Ki nh
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 trnh 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ế.

III. Những điểm y ếu tron g qu y trnh ph át triển ph ần m ềm (Software


Development Process)

Công ty N sử dụng một Quy trnh 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 trnh Phát triển phần mềm.
Quy trnh 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).

Trnh 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 trnh 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 trnh quản lư cơ bản bất kỳ cái ǵ.
- 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 trnh (workflow ma nagement) 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
trnh 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 trnh 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 trnh 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 trnh 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 trnh 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 trnh, 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 ǵ 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 trnh 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 trnh
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:
- Xác định database schema và data format của legacy system.
- Xây dựng database schema cho hệ thống mới trong Windchill’s Oracle
database.
- Viết m ột ch ương trnh đọc data base t ừ legacy s ystem 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 trnh viên trnh độ
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 trnh 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 trnh 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 ǵ 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 trnh viên trong một ngày đẹp trời tự nhiên thấy
máy tính của ḿ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á trnh 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ó đủ trnh độ, 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 trnh kh ông dịch được, hoặc
ClearCase view không thể update được là chuyện b́nh thường. Chương trnh
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 trnh đ̣i hỏi phải qua rất nhiều bước phức tap, và
không có chuẩn hóa. Quá trnh 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 trnh 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 trnh
chạy trở lại. Có nhiều lập trnh viên đến công ty chơi cả tuần v́ máy tính hỏng,
không có ǵ để 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 trnh 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á trnh 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 trnh 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 trnh. Sau khi hoàn thành việc lập trnh cho chức năng
(hoặc nhóm chức năng) này, bỗng nhiên quá trnh 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á trnh 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 trnh viên sẽ tạo ra các chức năng của chương trnh 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à trnh 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ư đă trnh 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 trnh 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 trnh để xem thông tin thực tế, yêu cầu và phân tích như thế
nào, được lập trnh 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 trnh, 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 ǵ cho ai. Có bao nhiêu iteration để lập trnh 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 trnh 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 ǵ 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á trnh lập trnh 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 trnh.
Một ví dụ điển h́nh là có trường hợp, một lập trnh 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 trnh viên này xem xét tại sao server code của ḿ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 trnh
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 trnh đú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 trnh hay v́ lư do ǵ khác, mà Ban Lănh đạo và Kế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.

IV. 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 ṃ 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 tṛ 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) và framework có thể mở rộng được.

Nhưng Dự án triển khai Windchill ở công ty N chỉ sử dụng một phần rất giới hạn
các chức năng của Windchill:
- Chức năng mô h́nh hóa các đối tượng (object modelling), mô h́nh hóa
các dịch vụ (service modelling), phát sinh mă chương trnh Java từ mô h́nh
(Java code 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.

Do thiếu hiểu biết về kiến trúc và các chức năng của Windchill, nên khi cần có
những chức năng rất sơ đẳng và cơ bản, Nhóm Phần mềm của Dự án phải làm
mới từ đầu, phát minh lại rất nhiều bánh xe, và do thiếu hiểu biết, nên những
thành phần (component) mới làm việc không được tốt với Windchill foundation,
và nhiều thành phần có tốc độ thi hành chậm (slow performance).
Một ví dụ điển h́nh v ề phát min h l ại b ánh x e tro ng d ự á n l à N Sear ch
Framework. Windchill Foundation cung cấp một Persistence Layer rất hoàn
chỉnh, với toàn bộ các chức năng về database query và database manipulation
từ cơ bản đến nâng cao, bao gồm hết toàn bộ các chức năng của SQL’92 và
phần mở rộng của Oracle SQL, phiên bản 8i và 9i. Nhưng do hoàn toàn không
biết cách sử dụng, Kiến trúc sư Phần mềm (Software Architect) và Ban Lănh đạo
Dự án quyết định xây dựng một cái gọi là N Search Framework, chỉ dùng để t́m
kiếm các đối tượng trong database. Từ khi N Search Framework ra đời, mỗi khi
cần t́m kiếm mỗi đối tượng trong database, thay v́ viết code mất khoảng 5 phút
sử dụng Persistence Layer, các lập trnh viên phải dùng Rational Rose để tạo
mẫu (model) cho 4 loại đối tượng khác nhau, viết 2 lớp đối tượng Search Criteria
và Search Result cho client side và viết code cho 4 lớp đối tượng Java ở server
side, cập nhật (update) 2 file cấu h́nh XML (XML configuration), mất ít nhất 1
ngày làm việc (8 tiếng). Việc t́m kiếm đối tượng trong database trở nên phức tạp
đến nỗi mỗi khi có một kiểu đối tượng mới, th́ phải dành hẳn một lập trnh viên
làm việc mất mấy ngày để viết code cho việc ghi đối tượng vào database và t́m
kiếm đối tượng.

Ngoài ra, hệ thống software của N hoàn toàn không có security và access
control, bất kỳ ai sau khi đă qua basic authentication với Webserver có thể thực
hiện tất cả mọi lệnh với tất cả các đối tượng trong hệ thống.

Không chỉ thiếu hiểu biết về enterprise software và Windchill, Kiến trúc sư phần
mềm (Software Architect) và Ban lănh đạo Kỹ thuật của Dự án tỏ ra thiếu hiểu
biết toàn diện về Phân tích/Thiết kế Hướng đối tượng (Object Oriented
Analysis/Design – OOA/OOD) và Lập trnh Hướng đối tượng (Object Oriented
Programming - OOP).
Về mặt phân tích (Analysis), tất cả những thực thể (entity) tham gia vào quá trnh
sản xuất trong User Story đều được tạo ra một object tương ứng trong Hệ thống
Phần mềm. Điều này là một sai lầm rất sơ đẳng của những học sinh mới học lập
trnh, v́ không phải tất cả các thực thể được kể trong quy trnh sản xuất đều là đối
tượng trong phần mềm, mà chỉ có một số nhất định là các đối tượng chính
(business object), một số là các mối quan hệ giữa các đối tượng (object
relationships) và một số chỉ là các thuộc tính của các đối tượng (attributes of
objects). Tất nhiên, trong Object Oriented Analysis/Design cũng tương tự như
trong Kiến trúc Xây dựng, không có câu trả lời tuyệt đối đúng, mà chỉ có câu trả
lời tốt hơn, và nằm trên ranh giới của nghệ thuật (Art) nhiều hơn là nằm trên
ranh giới của Kỹ thuật (Engineering). Nhưng trong thu thập thông tin sản xuất,
dịch vụ, có thực thể (entity) nào đều quy cả ra là object trong hệ thống phần
mềm th́ là một sai lầm ấu trĩ không thể tha thứ được.

Sau vài năm, sau khi có khái niệm về mối quan hệ giữa các đối tượng (object
relationships) và mối liên kết giữa các đối tượng (object-to-object link), Kiến trúc
sư Phần mềm lại tỏ ra hăng hái trong việc tạo ra object-to-object link đến nỗi có
nhiều business object được tạo mẫu (model) trong hệ thống như là các link.

Một sai lầm khác trong phân tích (OOA) là không xác định được Tính Tối thiểu
Và Đủ trong xây dựng đối tượng. Một ví dụ về Tính Tối thiểu và Đủ: Giả sử trong
một Hệ thống theo dơi Chuyên môn, có một lớp đối tượng là Programmer, th́
những thuộc tính mà hệ thống cần phải biết về một Lập trnh viên là Tên, Bằng
cấp, Trnh độ Lập trnh, Những kỹ năng chuyên môn, Khả năng đặc biệt, Số năm
kinh nghiệm, Quá trnh làm việc (Tùy theo hệ thống theo dơi Chuyên môn, có thể
có một vài thuộc tính nữa, nhưng với mục đích ví dụ, tôi giới hạn ở các thuộc
tính đề cập ở trên). Tất nhiên, ông lập trnh viên A có thể khác ông lập trnh viên B
ở chỗ ông th́ béo, ông th́ gầy, ông này là người Ấn Độ c̣n ông kia là người Mỹ,
ông th́ lái xe màu đỏ, ông th́ lái xe màu xanh ... Nhưng những thuộc tính như
Béo-Gầy, Ấn Độ - Mỹ - Xe màu đỏ - Xe màu xanh ... không phải là những thuộc
tính tiêu biểu cho việc theo dơi Chuyên môn , nên không được lưu trữ trong lớp
Programmer (Nhưng để mục đích theo dơi cá nhân, có thể được lưu trữ trong
lớp đối tượng Employee, nếu có). Như vậy, tập các thuộc tính Tối thiểu và Đủ
cho lớp P rogrammer l à (Tên, Bằng cấp, Trnh độ Lập trnh, Nh ững k ỹ năng
chuyên m ôn, K hả năng đặc b iệt, S ố năm k inh nghiệm, Qu á trnh l àm vi ệc ).
Nhưng do không xác định được tính Tối thiểu và Đủ, nên các đối tượng trong dự
án N thường có những thuộc tính chồng chéo, có trong nhiều lớp đối tượng có
quan hệ với nhau, tham khảo ḷng ṿng giữa các đối tượng, và có nhiều thuộc tính
đặt sai vị trí. Ví dụ về thuộc tính đặt sai vị trí: trong ví dụ ngoài lề ở trên, thuộc
tính về quốc tịch không đặt trong lớp Employee, mà đặt trong lớp Programmer.

Một sai lầm thô thiển khác là không phân biệt được lớp đối tượng (object class)
và một thể hiện của đối tượng (object instance). Ví dụ khi ta nói đến xe ô tô, tức
là ta nói đến một lớp (class) các xe ô tô nói chung, và khi ta nói đến chiếc ô tô
BMW có biển đăng kư XYZ 123, tức là ta nói đến một chiếc xe chính xác và cụ
thể, là thể hiện (instance) của lớp đối tượng ô tô. Chính v́ không phân biệt được
các khái niệm class và instance, trong Hệ thống Phần mềm của công ty N có
những trường hợp đặc biệt ấu trĩ như
- Trong hệ thống có các lớp đối tượng (class) And, lớp đối tượng Or, lớp
đối tượng Xor, lớp đối tượng Not, có các thuộc tính giống hệt nhau. Đúng
ra, tất cả các vật thể (entity) And, Or, Xor, Not kể trên đều thuộc về một
lớp đối tượng (class) gọi là Toán tử (Operator), và chúng chỉ là những thể
hiện (instance) có tên khác nhau là And, Or, Xor, Not.
- Trong hệ thống có những lớp đối tượng như Mũi giày, Đế giày, Dây giày,
Thân giày ... Đúng ra tất cả những vật thể (entity) kể trên đều thuộc về
một lớp đối tượng gọi là Chi tiết Giày (ShoePart) và có các tên gọi khác
nhau.

Một chiếc máy bay có hàng chục triệu chi tiết khác nhau, và nếu Hệ thống Phần
mềm cho Sản xuất máy bay ở Boeing, Airbus hay Lockheed Martin được cài đặt
theo phân tích và thiết kế như ở công ty N, th́ Hệ thống phải có hàng chục triệu
kiểu đối tượng (object type), và chỉ để viết code cơ bản cho các đối tượng cũng
phải mất vài ngh́n năm, chưa nói đến chuyện viết code cho cả hệ thống.

Công nghệ Hướng đối tượng (Object Oriented Technology) có ưu điểm là có


công cụ để xây dựng được các thành phần (component) có tính sử dụng lại
(reuse) cao, dễ bảo tr (easy to maintain), dễ phát triển, mở rộng (easy to extend).
Nhưng tính sử dụng lại (reuse), dễ bảo tr (easy to maintain) và dễ phát triển, mở
rộng (easy to extend) của các thành phần không phải tự nhiên mà có, mà phải
thông qua một quá trnh phân tích kỹ lưỡng, và phải được thiết kế một cách hợp
lư, c ó tính to án s âu s ắc v à tầm nh́n xa . Điều này phụ thuộc v ào quy trnh,
phương pháp làm việc và trnh độ của Kiến trúc sư phần mềm, chứ không phải là
điều sẵn có của Công nghệ Hướng đối tượng.

Có vẻ như Kiến trúc sư phần mềm (Software Architect) và Lănh đạo Kỹ thuật
trong dự án của công ty N chỉ biết đến những từ ngữ reuse, extensible qua sách
Nhập môn Lập trnh, chứ không có kiến thức thực tế, nên mặc dù các thuật ngữ
được sử dụng vung vít trong các tài liệu thiết kế và trong các cuộc họp, nhưng
hầu như không có thành phần nào trong hệ thống có thể sử dụng lại được, hoặc
dễ dàng mở rộng.

Một ví dụ điển h́nh là khi thiết kế một kiểu đối tượng (object type) để quản lư Vận
tải cho Đơn đặt hàng, Ban Lănh đạo Dự án quyết định là để cho kiểu đối tượng
ShipmentInfo có thể sử dụng được (reuse) cho việc quản lư gửi hàng cho nhiều
loại đối tượng khác nhau, không chỉ riêng cho Đơn đặt hàng, trong đối tượng
ShipmentInfo sẽ không có thông tin ǵ về Đơn đặt hàng trong đó.
Thế nhưng ShipmentInfo là đối tượng để quản lư Vận tải, tức là phải có nội dung
về hàng hóa được giửi trong chuyến gửi hàng đó. Thông tin về gửi hàng mà
không nói lên cái ǵ được gửi th́ sẽ được sử dụng vào đâu? Sau một thời gian
họp hành khá lâu, Ban Lănh đạo Dự án mới nhận ra điều hiển nhiên này. Thay v́
dùng một kiểu giao diện tổng quát (generic interface) gọi là ShipmentContent để
chứa thông tin về nội dung được gửi trong ShipmentInfo, và cài đặt những đối
tượng cụ thể được gửi trong Hóa đơn Vận tải như Đơn đặt hàng, Mẫu tiếp thị ,
Hàng bán Chính thức như là một implementation của interface ShipmentContent,
do đó ShipmentInfo có thể sử dụng lại để quản lư Vận tải cho tất cả các lớp đối
tượng có cài đặt (implement) ShipmentContent interface, th́ Kiến trúc sư phần
mềm và Ban Lănh đạo quyết định dùng rất nhiều liên kết (link) ḷng ṿng để diễn tả
thông tin và các mối quan hệ giữa một Hóa đơn Vận tải, Hàng được gửi và Địa
chỉ gửi hàng, làm tăng đáng kể độ phức tạp của các thao tác căn bản, lẽ ra phải
rất đơn giản như ghi Hóa đơn và Đơn đặt hàng vào database và đọc Hóa đơn và
Đơn đặt hàng từ database. Và cuối cùng, thực ra do mối liên kết thông qua các
link c̣n phức tạp và có mối ràng buộc cao hơn, nên đối tượng ShipmentInfo cũng
chẳng reuse được vào đâu.

Việc thiết kế các kiểu đối tượng một cách bừa băi, mỗi kiểu đối tượng tương ứng
với một thực thể trong thực tế, không có phân loại các đối tượng có cùng nhóm
chức năng, cùng có giao diện chung, làm cho mỗi kiểu đối tượng chỉ dùng được
cho một trường hợp cụ thể trong Hệ thống, không có tính sử dụng lại (reuse), và
mỗi lần cần mở rộng, bổ sung chức năng th́ chỉ có mỗi cách mở file Java code ra
viết lại.

Trong Thiết kế Hướng đối tượng (OOD), Kiến trúc sư Phần mềm (Software
Architect) và Ban Lănh đạo Dự án tỏ ra có một sự hiểu biết rất nông cạn và ấu
trĩ. Số lượng các Mẫu thiết kế (Design Pattern) được áp dụng vào dự án rất hạn
chế, và thường là áp dụng sai, mặc dù với yêu cầu và đặc điểm của dự án, thiết
kế hệ thống hoàn toàn rơi vào đại đa số các trường hợp điển h́nh để áp dụng
Mẫu thiết kế cơ bản (Basic Design Pattern) và Mẫu thiết kế J2EE (J2EE Design
Pattern).

Có duy nhất hai trường hợp áp dụng được Design Pattern một cách tương đối là
Business Delegate và Singleton Design Pattern, nhưng đó là do có ví dụ sẵn
trong Windchill foundation [4]. Trong Windchill foundation c̣n có nhiều ví dụ khác
về áp dụng Design Pattern, nhưng do thiếu kiến thức về Windchill và không đọc
Windchill document cũng như Windchill code, nên thiết kế của Dự án không áp
dụng được ǵ.

Trong khi đó, những ví dụ về áp dụng sai Design Pattern th́ nhiều không kể xiết.
Sai lầm cơ bản đầu tiên phải kể đến là áp dụng sai MVC Design Pattern [5], một
design pattern rất căn bản mà bất kỳ ai học nhập môn Lập trnh Hướng đối tượng
cũng phải biết. Mục đích chính của MVC Design Pattern là nhằm để tách biệt dữ
liệu (data) và phần hiển thị dữ liệu (view). Như vậy, trong đối tượng lưu trữ dữ
liệu sẽ không có logic về mặt hiển thị (presentation logic), và các đối tượng hiển
thị dữ liệu (view) chủ yếu là sử dụng các getters của đối tượng dữ liệu (model)
để lấy thông tin cần hiển thị. Trong khi đó, trong Dự án, các đối tượng tạm gọi là
Client Object lại có chứa các chức năng về hiển thị, như việc notify các GUI
component về việc thay đổi giá trị và một vài chức năng khác, do đó, các đối
tượng View và Model bị phụ thuộc rất chặt chẽ vào nhau.
Do sử dụng sai MVC Design Pattern, chèn logic hiển thị vào đối tượng mang dữ
liệu, nên các đối tượng mang dữ liệu để hiển thị khác với business object được
tạo ra và lưu trữ trong database. Như vậy, trong hệ thống có hai loại đối tượng
để biểu diễn cho cùng một dữ liệu là Client Object và Business Object (ví dụ, để
biểu diễn mẫu giày, ta có ClientShoe và BusinessShoe, ClientShoe được sử
dụng ở client side và BusinessShoe được sử dụng ở server side).

Do đó, khi cần hiện thông tin về business object (ví dụ như Mẫu giày hay Đơn
đặt hàng), cần phải có một quá trnh chuyển đổi từ Business Object sang Client
Object. Trong tất cả các phần của Dự án, mỗi khi cần ghi một Business Object
được tạo ra từ Client GUI vào database, th́ chỉ tốn khoảng 4 ḍng code để ghi
Business Object vào database, kể cả khởi tạo transaction, nhưng phải tốn kèm
vào đó khoảng 100 ḍng code để copy c ác thu ộc t ính t ừ Client O bject sang
Business Object (Đây là đă có cải tiến sau khi loại bỏ Data Transfer Object).

Do có nhu cầu gửi thông tin giữa các lớp (layer) khác nhau của Hệ thống, Kiến
trúc sư Phần mềm của Dự án nảy sinh ra ư định sử dụng một Design Pattern rất
cơ bản là Data Transfer Object (DTO). DTO Design Pattern đúng là được sử
dụng để truyền thông tin giữa các lớp (layer) khác nhau của một hệ thống phần
mềm nhiều lớp (multi-layer system), nhưng chỉ dùng trong những trường hợp
sau đây:
- Dùng để gửi nhiều thông tin rời rạc trong cùng một lần gửi. (Ví dụ như để
gửi username và password từ cửa sổ login tới authentication service để
kiểm tra, thay v́ gửi hai String riêng biệt username và password, mất hai
lần communication qua các layer, chương trnh sẽ đóng gói username và
password thành thuộc tính của một đối tượng là AuthenticationInfo và gửi
đối tượng này đi, như vậy chỉ tốn một lần communication).
- Dùng để làm giảm số lần giao tiếp từ xa (remote request) trên mạng.
Nhiều thông tin (nhiều thuộc tính hoặc nhiều đối tượng) sẽ được đóng gói
vào trong một đối tượng là Data Transfer Object và gửi qua các thành
phần phân tán (distributed component) trên mạng, do đó làm giảm số lần
trao đổi qua lại trên mạng, làm giảm network traffic và tăng application
performance. Ví dụ như client có yêu cầu cần biết về Đơn đặt hàng
(Sample Request) và Thông tin Vận tải (ShipmentInfo) của Đơn đặt hàng,
thay v́ gửi Sample Request và ShipmentInfo trong hai lần gọi API qua
mạng, th́ hệ thống s ẽ đ óng gói Sam ple R equest v à ShipmentInfo vào
trong một DTO object và gửi trong một lần gọi API qua mạng. (Đáng tiếc
là hệ thống tại công ty N không được thiết kế như vậy).

Trong dự án tại công ty N, DTO Design Patter được sử dụng như sau: Bởi v́ có
hai loại đối tượng khác nhau biểu diễn cho cùng một dữ liệu là Client Object ở
client side và Business Object ở server side, nên để truyền dữ liệu từ client side
đến server side và ngược lại, hệ thống sẽ sử dụng một loại đối tượng thứ ba gọi
là Data Transfer Object (DTO).
Như vậy, trong hệ thống, tương ứng với mỗi loại dữ liệu sẽ có 3 loại đối tượng
khác nhau là Client Object ở client side, Business Object ở server side và DTO
Object dùng để gửi thông tin giữa client và server. Ví dụ một mẫu giày sẽ có
ClientShoe, BusinessShoe và DTOShoe.
Quá trnh ghi một mẫu giày được thiết kế từ GUI vào database sẽ được tiến hành
như sau:
- Tại client side: Copy các thuộc tính (attributes) từ ClientShoe vào DTOShoe.
- Gửi DTOShoe tới server.
- Tại server side: Copy các thuộc tính từ DTOShoe vào BusinessShoe.
- Ghi BusinessShoe vào database.

Việc áp dụng DTO Design Pattern ở đây không làm giảm số lượng các thông tin
rời rạc được gửi từ client tới server, v́ thông tin trong ClientShoe và DTOShoe về
mặt cơ bản là như nhau. DTO trong trường hợp này cũng không làm giảm số lần
communication qua mạng, v́ dù gửi ClientShoe hay gửi DTOShoe từ Client đến
server cũng tốn một lần gửi một đối tượng.
Ngược lại, áp dụng DTO như trnh bày ở trên tăng thêm 100 ḍng code để copy
các th uộc t ính t ừ ClientShoe sang DTOSh oe v à 100 ḍng c ode để copy t ừ
DTOShoe sang BusinessShoe.

Sau 4 năm t́m ṭi, nghiên cứu một cách cần cù và gian khổ, có lẽ nhận ra sự ngu
xuẩn của việc áp dụng DTO Design Pattern một cách sai lầm của ḿnh, Kiến trúc
sư Phần mềm và Ban Lănh đạo Dự án quyết định loại bỏ DTO Object, và gửi
thẳng Client Object đến server side để copy sang Business Object. Việc làm này
được Ban Lănh đạo Dự án đánh giá như một phát kiến vĩ đại, một bước đột phá
để tăng năng suất lập trnh (Programming Productivity), v́ cho mỗi kiểu đối tượng,
bớt đi được 100 ḍng cod e phải vi ết, v à tăng t ốc độ thi hành ch ương trnh
(Program Performance), v́ bớt đi 100 ḍng code phải thi hành.
Nhưng bỏ DTO đi th́ lại phát sinh ra một vấn đề mới là lúc này ClientObject có
mang client code và logic hiển thị (presentation logic) được gửi tới server code,
mà xuyên qua rất nhiều layer, đến tận Persistence Layer. Điều này đă phá vỡ
hoàn toàn sự linh hoạt (flexibility) của một kiến trúc phần mềm nhiều lớp (multi-
layer architecture), và làm cho client và server bị ràng buộc chặt chẽ (tightly-
coupled) vào nhau. Một thay đổi nhỏ trong client code cũng sẽ dẫn đến thay đổi
trong rất nhiều lớp của server code, từ business layer đến persistence layer và
trong rất nhiều trường hợp, thậm chí thay đổi cả database schema. Thiết kế
thiên tài này của công ty N đă đưa chúng ta về lại những năm 70 của thế kỷ 20
với k iến tr úc phần m ềm 2 lớp (2-tier) client-server, Lập trnh có cấu tr úc
(Structural Programming) và gọi hàm từ xa (Remote Procedure Call).
Đồng thời sự phụ thuộc của server vào client code thông qua việc sử dụng Client
Object trong server code làm cho trong rất nhiều trường hợp, việc phát triển
song song server code và client code không thể thực hiện được, v́ lập trnh viên
cho server code phải ngồi chơi, chờ đến khi lập trnh viên cho client code hoàn
thành việc lập trnh cho Client Object. Do sự quản lư yếu kém và thiếu phối hợp
trong Dự án, có nhiều trường hợp, lập trnh viên cho client code viết code cho
cửa sổ, menu và các đối tượng GUI trước khi viết code cho Client Object, và lập
trnh viên cho server code được hưởng niềm vui là ngồi chờ lâu hơn nữa.

Một Giải pháp tốt cho t́nh trạng này là thiết kế một Client tốt, tuân thủ chặt chẽ
MVC Design Pattern, tức là không có presentation logic trong data model. Như
vậy, Business Object sẽ được sử dụng như là một biểu diễn duy nhất cho một
loại dữ liệu trong cả hệ thống, từ Persistence Layer tới Business Layer và
Presentation Layer. Business Object sẽ được dùng để gửi thông tin về đối tượng
giữa các lớp (layer) của hệ thống, và sẽ được dùng làm model trong hệ thống
MVC của GUI.

Ngoài ra, do không phân biệt được các Design Patterns Delegate, Template và
Strategy, các khái niệm và cài đặt được sử dụng một cách lung tung, bừa băi và
dẫn đến những cài đặt cực kỳ rắc rối, phức tạp (overly complicated
implementation), dẫn đến khó bảo tr, phát triển và làm chậm tốc độ chạy chương
trnh.

Ở trên chỉ là một vài ví dụ trong rất nhiều trường hợp sử dụng sai Design Pattern
trong Software Architecture của công ty N.

Hiểu biết về những nguyên tắc căn bản trong Lập trnh Hướng đối tượng (OOP
Fundamentals) của Ban Lănh đạo Dự án cũng không khá hơn bao nhiêu so với
hiểu biết về OOA/OOD. Những sai lầm về OOP Fundamentals trong dự án có rất
nhiều, nhưng tôi chỉ dẫn ra một vài ví dụ điển h́nh.

Có một khẩu hiệu mà bất kỳ một lập trnh viên tập việc nào cũng có đọc qua ít
nhất một lần “Code to interfaces, not code to concrete implementations”, nghĩa là
“Lập trnh gọi đến giao diện, chứ không gọi đến các lớp cài đặt cụ thể.” . Mục
đích của việc làm này là để tách riêng chức năng (functionality) khỏi các cài đặt
cụ thể (implementation). Điều này có nghĩa là các thành phần (component) và
các lớp (layer) của một hệ thống phần mềm chỉ giao tiếp với nhau thông qua một
hệ thống chức năng/dịch vụ được định nghĩa trước, c̣n việc cài đặt các chức
năng/dịch vụ đó như thế nào th́ phụ thuộc vào các lớp cài đặt cụ thể (concrete
implementation). Tuy nhiên, các lớp cài đặt cụ thể này không được bộc lộ
(expose) ra khỏi component và layer, nên khi cách cài đặt hoặc thuật toán cho
chức năng thay đổi, các component và layer khác hoàn toàn không bị ảnh
hưởng, hoặc ảnh hưởng rất ít. Điều này làm tăng tính sử dụng lại, dễ bảo tr và
dễ phát triển của component và của cả hệ thống. [6]

Nhưng do không biết (hoặc không hiểu) khẩu hiệu này, nên trong Hệ thống của
công ty N, mặc dù trong hệ thống có định nghĩa các interface, nhưng các hàm
API để giao tiếp giữa các lớp (layer) và các thành phần (component) của hệ
thống chủ yếu sử dụng các lớp cụ thể (concrete class) như là tham số
(parameters, arguments) và giá trị trả về (return value).
Một sai lầm khác về OOP Fundamentals trong dự án của công ty N là không
phân biệt nổi Mở rộng chức năng cho đối tượng bằng Inheritance (Kế thừa) và
Mở rộng bằng Composition (tạm dịch là Bao gồm) hoặc Mở rộng bằng Design
Pattern (ví dụ Decorator Pattern và Visitor Pattern), do đó, trong tất cả các phần
của dự án, việc mở rộng, bổ sung chức năng cho các lớp đối tượng được thực
hiện một cách duy nhất bằng Inheritance, tạo ra những họ (family) các lớp đối
tượng lớn, các thành viên thực chất chả có liên quan đến nhau mấy, mà chỉ
được tạo ra bởi nhu cầu mở rộng chức năng.[7]

Trong một hệ thống enterprise software, XML đóng một vai tṛ rất quan trọng. Và
trong dự án tại công ty N, việc sử dụng XML cũng có nhiều sai lầm, bao gồm cả
Lạm dụng XML (Overuse XML) và Sử dụng không hết chức năng của XML
(Underuse XML).

Trnh bày về chức năng và phương pháp sử dụng XML trong Enterprise Software
Development hoàn toàn không nằm trong phạm vi bài viết này. Tôi chỉ xin dẫn ra
một vài sai lầm căn bản trong việc sử dụng sai lầm trong dự án tại công ty N.

Một trong những sai lầm nghiêm trọng trong sử dụng XML trong dự án là đa số
các file XML được viết trong quá trnh phát triển dự án hoàn toàn không có biểu
diễn cấu trúc và kiểm tra cấu trúc thông qua DTD (Document Type Definition)
hoặc XSD (XM Schema Definition). Điều này dẫn đến t́nh trạng khá nguy hiểm là
cấu trúc của file XML có thể bị thay đổi một cách bừa băi, và có thể dẫn đến việc
hệ thống hoạt động sai, sinh ra các lỗi thi hành (run-time error) nghiêm trọng.

Trường hợp điển h́nh về việc lạm dụng XML xảy ra trong việc xây dựng một hàm
tiện ích ở server side có tên là getServerObject để t́m kiếm một Business Object
trong database khi biết kiểu đối tượng ClientObject và Unique Identification của
object này vào thời điểm mà hàm API được gọi. Như đă trnh bày trong phần
trên, cho một kiểu dữ liệu nhất định, có ít nhất hai kiểu đối tượng tương ứng là
ClientObject và BusinessObject. Quan hệ giữa ClientObject và ServerObject là
quan hệ 1:1, điều này có nghĩa là vào thời điểm hàm getServerObject được gọi,
nếu ta biết kiểu đối tượng (object type) của ClientObject, th́ có nghĩa là ta cũng
biết kiểu của BusinessObject, và chỉ việc gọi lệnh t́m kiếm trong database cho
BusinessObject.
Tuy nhiên, theo yêu cầu của Kiến trúc sư Phần mềm (Software Architect) và Ban
Lănh đạo Dự án, nhằm mục đích tăng tính linh hoạt của hệ thống (?), vào lúc gọi
hàm getServerObject, mặc dù đă biết rất rơ kiểu của ClientObject, ta phải giả vờ
không biết kiểu của BusinessObject, và phải t́m trong một XML mapping file để
xem k iểu (type) của Bu sinessObject l à ǵ, rồi m ới g ọi l ệnh t́m k iếm trong
database cho BusinessObject. Ở đây, việc tồn tại của XML file và XML lookup là
hoàn toàn thừa và làm giảm tốc độ thực hiện chương trnh.

Trường hợp điển h́nh về không sử dụng hết chức năng của XML nằm trong N
Search Framework dùng để t́m kiếm object trong database. Như đă trnh bày ở
trên, framework này là hoàn toàn thừa, và tạo nhiều rắc rối cho lập trnh viên
nhiều hơn là tạo công cụ. Framework này không chỉ có vấn đề về mặt chức
năng, mà c̣n có rất nhiều vấn đề về mặt cài đặt. Một trong những vấn đề đó là:
Đối với mỗi loại đối tượng (object type) khác nhau, cần phải có rất nhiều loại đối
tượng phụ trợ (helper object) đi kèm th́ mới thực hiện được việc t́m kiếm. Và
riêng về một hàm API phục vụ cho việc t́m kiếm, mỗi loại đối tượng phải có một
hàm getObject khác nhau, trong đó sự khác biệt giữa các hàm getObject của các
loại đối tượng khác nhau là:
- Thêm c ác thu ộc t ính (attribute) làm điều k iện t́m ki ếm và cần l ấy t ừ
database vào một danh sách các thuộc tính.
- Lấy ra các giá trị (value) của thuộc tính của đối tượng từ kết quả trả về.

Các bước tiến hành khác trong các hàm API getObject này là giống hệt nhau.
Như vậy có thể dùng một file XML để lưu các thuộc tính làm điều kiện t́m kiếm
và các thuộc tính cần lấy từ database cho từng loại đối tượng. Sau đó viết một
hàm getObject cho tất cả các loại đối tượng (object type), trong đó kiểu đối ượng
được truyền làm tham số cho hàm getObject, và tại hai phần khác biệt kể trên,
chương trnh sẽ căn cứ vào tham số object type để phân tích file cấu h́nh XML và
t́m ra những điều kiện t́m kiếm và thuộc tính trả về cho từng loại đối tượng thích
hợp. Nhưng đáng tiếc, trong cài đặt của N Search Framework, có hàng chục
hàm getObject cho hàng chục kiểu đối tượng khác nhau, trong đó sự khác nhau
giữa hàng chục hàm getObject này chỉ nằm ở hai bước có thể dùng XML để định
cấu h́nh (configure) như đă miêu tả ở trên. Với đà phát triển hiện nay của dự án,
số lượng các kiều object (object type) hoàn toàn có thể lên tới hàng ngh́n, và sẽ
có hàng ngh́n hàm getObject đ̣i hỏi phải có sự bảo tr và sửa đổi mỗi khi có một
sửa đổi trong thiết kế hoặc từ thực tế sản xuất.

C̣n rất nhiều những sai lầm trong phân tích và thiết kế hệ thống cũng như việc
thực hiện dự án, nhưng khuôn khổ bài viết có hạn, hơn nữa, những sai lầm c̣n
lại mặc dù có những sai lầm nghiêm trọng nhưng không có tính điển h́nh, và
phần nhiều là hệ quả của sự thiếu kiến thức, kinh nghiệm và những sai lầm đă
có phân tích, v́ thế tôi không đề cập tới.

V. Những bài học rút ra từ Dự án


Một quy trnh tốt, được thực hiện đủ tất cả các bước không bảo đảm cho sự
thành công của một Dự án phần mềm. Quy trnh được sử dụng trong Dự án của
công ty N là Rational Unified Process, một quy trnh chuẩn công nghiệp được sử
dụng rộng răi trong phát triển phần mềm, nhưng do chi tiết thực hiện từng bước
sai, nên không đem lại kết quả.

Sử dụng những công nghệ tốt, theo chuẩn công nghiệp không bảo đảm cho sự
thành công của một Dự án phần mềm. Công nghệ được sử dụng trong Dự án
của công ty N là J2EE và Oracle database, là những công nghệ tốt nhất hiện nay
cho Enterprise Software, có chuẩn công nghiệp và chi tiết kỹ thuật (Technical
Specification) rơ rang, với đầy đủ các công cụ (tool) và tiện ích (utility) để phát
triển. Nhưng do sử dụng không có phương pháp, nên kết quả vẫn là phần mềm
chắp vá, kém chất lượng, không sử dụng được.

Những công cụ lập trnh và phần mềm tiện ích tốt cũng không đảm bảo cho sự
thành công của một dự án phần mềm. Các công cụ được sử dụng trong dự án
như ClearCase,Rational Rose, Eclipse, Aphelion, Apache, Tomcat … đều là
những công cụ đă được thử thách và chứng tỏ là tốt trong Công nghệ Phần
mềm. Nhưng do sử dụng không đúng, nên không giúp ích được nhiều cho quá
trnh làm việc, và không tạo ra được sản phẩm tốt

Con người chính là khâu quan trọng nhất trong một Dự án Phần mềm. Chính v́
Ban Lănh đạo Dự án và Kiến trúc sư Phần mềm của Dự án không có đủ năng
lực để quản lư, thiết kế và thi hành Dự án, nên Dự án mới dẫn đến t́nh trạng như
đă trnh bày trong bài viết.

Khi bắt tay vào việc tiến hành một Hệ thống Phần mềm, việc đầu tiên là phải t́m
được một đội ngũ nhân sự có trnh độ thích hợp với quy mô và độ phức tạp dự
tính sẽ có của Dự án, sau đó mới tiến hành thu thập thông tin, phân tích thiết kế
và thực hiện.

Thực ra, phần chuẩn bị Nhân sự chính là phần khó khăn nhất của một Dự án
phần mềm, v́ nhiều công ty sản xuất và dịch vụ không có sẵn chuyên gia và
nhân viên kỹ thuật có trnh độ Phần mềm cao để có thể phỏng vấn và tuyển
người cho Dự án. Ngay cả khi công ty sản xuất và dịch vụ có bộ phận IT riêng,
th́ những người trong các bộ phận này thường không có trnh độ cao, v́ yêu cầu
công vi ệc th ường xu yên h àng ng ày kh ông đ̣i h ỏi nhân vi ên ph ải có trnh độ
chuyên môn cao. Hơn nữa, khi khởi đầu việc tuyển người cho bộ phận IT nội bộ,
có rất nhiều khả năng là công ty sản xuấtvà dịch vụ không có người có đủ trnh
độ để phỏng vấn và xét tuyển nhân viên.

Giải pháp cho vấn đề nhân sự cho những Dự án phần mềm lớn và phức tạp là:
Đầu tiên phải thuê một trong những công ty Tư vấn về Giải pháp Công nghệ
Thông tin để thu thập thong tin sơ bộ và làm phác thảo ước tính về quy mô cũng
như Độ Phức tạp của Dự án. Sau đó dựa vào những công ty Cung cấp Nhân sự
chuyên nghiệp để thuê những nhân viên quản trị Dự án (Project Manager) và
Kiến trúc sư Phần mềm (Software Architect) có năng lực , để làm nhiệm vụ lănh
đạo Dự án, thu thập thong tin, phân tích đánh giá, lựa chọn công nghệ, công cụ,
ngôn ngữ lập trnh, phác thảo thiết kế …

Làm theo cách này, sẽ đảm bảo được tính chuyên môn hóa cao, v́ các công ty
chuyên về Tư vấn về Giải pháp Công nghệ Thông tin có chuyên môn cao trong
việc thu thập thông tin thực tế và phác họa giải pháp, các công ty Cung cấp
Nhân sự có chuyên môn cao và có chuyên gia với trnh độ chuyên ngành cần
thiết trong việc t́m kiếm, phỏng vấn và xét tuyển nhân viên. Tuy nhiên, do nhu
cầu thị trường lớn, nên có nhiều công ty cung cấp dịch vụ Tư vấn Giải pháp và
Cung cấp Nhân sự hoạt động, và rất nhiều trong số đó không có đủ kinh nghiệm,
trnh độ và kiến thức cần có cho những Dự án có quy mô lớn và phức tạp. Do đó,
việc chọn công ty Tư vấn Giải pháp và Cung cấp Nhân sự để thuê cần phải
được tiến hành hết sức cẩn thận.

Sau khi hoàn thành tốt khâu Chuẩn bị Nhân sự, th́ các khâu khác của Dự án sẽ
được tiến hành một cách thuận lợi, v́ những Quản trị Dự án và Kiến trúc sư
Phần mềm có kinh nghiệm, kiến thức sẽ biết phải điều hành dự án theo những
Quy trnh nào, tiến hành việc thu thập thông tin, phân tích, hệ thống, đánh giá ra
sao, tổ chức đội ngũ và giao tiếp giữa các nhóm làm việc như thế nào, tuyển lập
trnh viên và nhân viên phân tích với tiêu chuẩn trnh độ sao cho phù hợp, lựa
chọn công cụ, tiện ích để quản lư, theo dơi công việc và công cụ lập trnh một
cách tối ưu. Tất nhiên, các công việc kể trên không phải là dễ dàng, nhưng với
một đội ngũ Lănh đạo tốt, có kinh nghiệm, kiến thức th́ khả năng tiến hành tốt
các bước của Dự án sẽ rất cao, và Dự án có khả năng thành công đúng thời hạn
và trong phạm vi ngân sách.

Hy vọng là qua study case này, bạn đọc sẽ rút ra được những điểm yếu có thể
xảy ra trong những khía cạnh khác nhau của một Dự án Phần mềm như Quy
trnh Quản lư Dự án (Project Management Process), Quy trnh Phát triển Phần
mềm (Software Development Process) và Kiến trúc Phần mềm (Software
Architecture) và qua những giai đoạn (phase) khác nhau của một chu kỳ phát
triển phần mềm (Software Development Lifecycle) như Khởi đầu (Inception), Dự
thảo Chi tiết (Elaboration), Thực hiện xây dựng (Construction). Có điều, các giai
đoạn được trnh bày về Dự án tại công ty N này không phải là một Chu kỳ phát
triển Phần mềm đầy đủ (Full Lifecycle Software Development) v́ Dự án chưa có,
và rất có thể không bao giờ có giai đoạn Chuyển giao (Transition).

U.S.A. 1-8-2005
JMS
------------------------------------------------
Chú thích
[1] Trước đây tôi đă từng làm việc vài năm trong vị trí là Senior Software
Engineer, Software Architect và R&D Team leader trong Windchill R&D
(Research and Development) của PTC.

[2] Trong thời gian làm trong Windchill R&D, ngoài công việc nghiên cứu phát
triển công nghệ và thiết kế Windchill foundation, tôi có tham gia hỗ trợ trực tiếp
cho dự án triển khai Windchill ở Rolls Royce (Anh), Airbus (Pháp) và Tokyo
Electron (Nhật).

[3] Frederik Phillips Brooks, Jr.: Kenan Professor of Computer Science,


Department of Computer Science, University of North Carolina
Ông tốt nghiệp Cử nhân Khoa học ngành Vật lư với điểm tuyệt đối trong toàn bộ
quá trnh học (summa cum laude) trường Duke, Master và Ph.D. toán ứng dụng
trường Harvard. Ông đă tham gia giảng dạy nhiều năm, làm nghiên cứu trong Bộ
phận Nghiên cứu và Phát triển Công nghệ của IBM, tham gia Ban Nghiên cứu
của Bộ Quốc pḥng và nhiều Ủy ban Nghiên cứu Liên bang và Quốc gia khác.
Các giải thưởng, huy chương về Phát minh và Công nghệ của ông được trao bởi
Học Viện Hoàng gia Anh, Học viện Hoàng gia Hà lan, Viện nghiên cứu Liên bang
Thụy sĩ, của các Viện nghiên cứu, trường Đại học và Ủy ban Quốc gia của Mỹ
nếu liệt kê hết phải tốn nhiều trang giấy khổ A4. Ông có hai bằng Phát minh
Sáng chế của Mỹ (U.S. Pattern) trong lĩnh vực Computer Science. Ông đă tham
gia quản trị nhiều dự án nghiên cứu công nghệ và phát triển phần mềm trong
công nghiệp.
Danh mục các tác phẩm khoa học bao gồm sách, bài viết, tài liệu nghiên cứu …
nếu được liệt kê cũng tốn rất nhiều trang A4.

[4] Có một trường hợp áp dụng Memento Design Pattern trong Swing GUI của
Dự án cũng khá lư thú, nhưng là do sáng tạo của một Swing Developer chứ
không phải nằm trong thiết kế của dự án. Lác đác trong Java code của dự án
cũng có một vài chỗ có ứng dụng tốt Design Pattern, nhưng toàn bộ là do các
lập trnh viên giàu kinh nghiệm trong dự án áp dụng, chứ không có trong tài liệu
thiết kế (Design Document) và Mô h́nh Đối tượng (Object Model), và không phải
từ Ban Lănh đạo Dự án và Kiến trúc sư phần mềm mà có.

[5] MVC: Model-View-Controller. Chi tiết về lư thuyết và ví dụ về ứng dụng MVC


Design Pattern trong lập trnh Java có thể t́m thấy trong PC World Vietnam tháng
5 năm 2005.

[6] Trong ngôn ngữ lập trnh Java, interface có 4 chức năng rất quan trọng:
- Java không hỗ trợ (support) việc thừa kế từ nhiều lớp đối tượng (multiple
inheritance), do đó interface cung cấp công cụ để một lớp đối tượng có
thể cài đặt (implement) nhiều interface, và qua đó thừa kế các hành vi
(behavior) của nhiều loại đối tượng khác nhau.
- Java interface tách biệt chức năng (functionality) và cách cài đặt chức
năng (implementation). Đây là một đặc điểm rất quan trọng, giúp cho các
thành phần (component) trong một hệ thống OOP có thể tương tác với
nhau, nhưng không phụ thuộc chặt chẽ vào cách cài đặt của nhau, do đó
các thành phần có thể được dùng lại trong nhiều hệ thống, dễ bảo tr, mở
rộng.
- Java interface có tác dụng như một sự đánh dấu (marker interface), xác
định với hệ thống là nếu một lớp đối tượng (class) cài đặt (implement) một
interface, th́ lớp đối tượng này có thể được hệ thống thao tác và sử dụng
theo một số phương pháp nhất định. Một ví dụ về marker interface là
Serializable interface.
- Java interface có tác dụng là định nghĩa các phương thức (method) nhằm
mục đích bắt buộc những lớp đối tượng (class) nào cài đặt (implement)
interface này, th́ cũng p hải c ó những ph ương th ức (method) có trong
interface. Chức năng này dung để thiết kế các framework mà các hành vi
cụ thể có thể mở rộng hoặc thay đổi cách thực hiện trong tương lai, hoặc
các hành vi phải được thực hiện đă biết, nhưng cách thức thực hiện th́
chưa được biết v ào th ời điểm vi ết ch ương trnh, m à chỉ biết kh i chạy
chương trnh (run-time) . Trong design pattern, chức năng này được sử
dụng nhiều trong Template Method và Strategy pattern.

[7] Một ví dụ về mở rộng chức năng thông qua Kế thừa (Inheritance) và thông
qua Bao gồm (Composition).
Giả sử trong một hệ thống dữ liệu về hàng điện tử ta có nhiều loại thiết bị cần
quản lư, trong đó có Phone(Điện thoại), Camera (máy ảnh), CameraPhone
(Điện thoại có máy ảnh) và Digital Camera (Máy ảnh kỹ thuật số).

Ta nhận thấy CameraPhone có chức năng của Phone và Camera, có thể được
mở rộng từ Phone và Camera. DigitalCamera thuộc về họ Camera, và có thể
được mở rộng từ Camera.

Mở rộng thông qua kế thừa: Trong Java không có thừa kế từ nhiều lớp (multiple
Inheritance), nên ta phải định nghĩa Camera và Phone là Interface, và định nghĩa
CameraPhone là implementation của các interface Camera và interface Phone.
Như vậy trong lớp CameraPhone, ta phải viết code cho các chức năng của
Phone và Camera. Tương tự, ta có thể định nghĩa DigitalCamera là
implementation của Camera, và trong Camera, ta phải viết code cho các chứ
năng của Camera.
Lợi: Xây dựng được một hệ thống các lớp đối tượng có chung một số chức năng
nhất định (ví dụ như DigitalCamera và CameraPhone có chung chức năng chụp
ảnh).
Hại: Trùng lặp code (trong DigitalCamera và CameraPhone cùng có code cho
chức năng chụp ảnh, và rất có thể là hoàn toàn giống nhau, v́ cùng là chụp ảnh
digital). Dễ gây ra tính thiếu tự nhiên trong thiết kế và lỗi khi chạy chương trnh (ví
dụ như một API dành cho interface Phone được gọi và truyền cho tham số là
CameraPhone, sau đó dùng reflection để gọi các method trên đối tượng được
truyền làm tham số, rất có thể API này sẽ gọi cả chức năng của Camera, là điều
hoàn toàn sai và không được dự tính cho API này). Tạo ra nhiều lớp đối tượng
một cách không cần thiết (mỗi lần cần mở rộng tính năng lại phải dẫn suất
(derive) ra một lớp đối tượng mới).

Mở rộng thông qua Bao gồm (Composition)


Ta định nghĩa Phone như một class có các chức năng của điện thoại, và Camera
là một class có chức năng của máy ảnh. Như vậy CameraPhone được định
nghĩa như một lớp đối tượng có hai thành viên (member variable) là Camera và
Phone. Khi chức năng Phone của CameraPhone được gọi, CameraPhone sẽ
gửi lệnh gọi này tới biến thành viên (member) Phone, và khi chức năng Camera
của CameraPhone được gọi, CameraPhone sẽ gửi lệnh gọi này tới thành viên
Camera. Đối với DigitalCamera, ta có chọn lựa rộng răi hơn, có thể kế thừa
(inherit) và định nghĩa chồng (override) các chức năng của Camera, hoặc các
chức n ăng được cài đặt cơ bản l à giống nhau, th́ có thể đ ịnh nghĩa
DigitalCamera có một biến thành viên là Camera, và gửi các lệnh gọi về chức
năng của Camera tới thành viên này.

Lợi: Giảm được sự trùng lặp code. Tạo ra các chức năng mới một cách dễ dàng
bằng cách bổ sung biến thành viên.
Hại: Trong trường hợp đối tượng mới cần có chức năng khác hơn chức năng có
sẵn của biến thành viên (ví dụ chức năng chụp ảnh của DigitalCamera khác
chưa năng chụp ảnh của Camera, c̣n các chức năng như nạp pin, lau ống kính
th́ giống), sẽ có dư thừa code (v́ chức năng chụp ảnh phải viết mới, trong khi đó
trong biến thành viên Camera cũng có chức năng chụp ảnh).

Tất nhiên, không có luật tuyệt đối đúng (hard and fast rule) cho việc trong trường
hợp nào th́ phải mở rộng chức năng bằng Inheritance, trong trường hợp nào th́
phải sử dụng Composition hay Design Pattern. Có một khẩu hiệu cũng khá nổi
tiếng trong giới lập trnh “Prefer composition over Inheritance”. Tuy vậy, điều này
phụ thuộc vào yêu cầu thực tế, trnh độ, kỹ năng kinh nghiệm của kiến trúc sư
phần mềm (Software Architect), và có tính nghệ thuật cao.
Nhưng một Dự án phần mềm mà chỉ có mở rộng chức năng đối tượng bằng
Inheritance (trong khi có những trường hợp dùng các phương pháp khác tốt
hơn) là tuyệt đối không được, thể hiện trnh độ kém và thiếu hiểu biết của kiến
trúc sư phần mềm.

You might also like