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

Những học từ dự án phần mềm Những học từ dự án phần mềm Bởi Châu Hồng Lĩnh | Ngày 02 Tháng hai, 2007 :: 15h23 _ Đây câu chuyện có thật dự án phần mềm trải qua năm tiêu tốn 35 triệu USD mà không đem lại kết nào, có kế hoạch kéo dài thêm năm Dự án diễn công ty sản xuất dụng cụ thể thao vào hàng đầu giới, doanh thu khoảng chục tỷ USD năm, có trụ sở Tây Bắc Mỹ, tạm gọi công ty N Trên phương diện study case, dự án độc đáo, dùng làm học điển hình nhiều khía cạnh khác dự án phần mềm, dành cho doanh nghiệp sản xuất, dịch vụ có ý định ứng dụng công nghệ thông tin vào quy trình sản xuất hoạt động Bài viết hướng tới đối tượng Giám đốc Công nghệ Thông tin doanh nghiệp (CIO – Chief Information Technology Officer), Quản trị Dự án (Project Manager) Kiến trúc sư phần mềm (Software Architect), phân tích qua khía cạnh sau dự án: Quy trình Quản lý (Management Process), Quy trình phát triển phần mềm (Software Development Process) Kiến trúc phần mềm (Software Architecture) Giới thiệu tổng quát dự án tổ chức nhân _ Dự án dự án xây dựng hệ thống enterprise software nhằm mục đích phối hợp (collaborate) hoạt động phận hệ thống sản xuất giày dép (Footwear Production) công ty N khắp 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, vẽ mẫu giày dép, tài liệu 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ý dự án cho 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 phận khác công ty N, từ Bộ phận Thiết kế mẫu sản phẩm Bắc Mỹ đến Nhà máy sản xuất giày dép đặt châu Á Nhà cung cấp nguyên vật liệu khắp giới Bao gồm việc lưu chuyển quản lý cách tự động việc đưa mẫu thiết kế từ Bắc Mỹ đến sản xuất thử nghiệm châu Á, đến việc thử nghiệm, thu thập thông tin sản phẩm mẫu, cải tiến, sản xuất thức tiêu thụ, tự động theo dõi hệ thống lưu chuyển nguyên vật liệu vận tải sản phẩm Trước đây, công ty có thời kỳ sử dụng mainframe computer COBOL, sau tới thời kỳ sử dụng Power Builder SAP để quản lý số phần nhỏ quy trình sản xuất Hiện Những học từ dự án phần mềm nay, công ty muốn xây dựng hệ thống hoàn chỉnh, toàn diện với công nghệ Công nghệ sử dụng dự án J2EE Oracle database Application Server Apache Webserverkết nối với Tomcat servletengine Dự án xây dựng hoàn toàn từ đầu (build from scratch), mà dựa enterprise platform tiếng loại phần mềm PDM/PLM (Product Data Management/Product Lifecycle Management) Enterprise Collaboration Software, có tên Windchill Windchill sản phẩm J2EE công ty PTC (Parametric Technology Corp.), trụ sở bang Massachusetts, Mỹ [1] Đây phần mềm tảng (platform), cung cấp toàn sở hạ tầng chức cho 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 phận khác công ty, với công ty khác, với nhà cung cấp khách hàng thường xây dựng từ đầu, mà mua Windchill (hoặc sản phẩm tương tự, ví dụ Matrix One, EDS, SAP, People Soft, IBM Dassault …) về, cải biến cài đặt thêm (customization) platform có sẵn để phù hợp với đặc điểm riêng doanh nghiệp, đưa vào sử dụng Hiện có khoảng 3000 công ty sản xuất lớn giới sử dụng Windchill để điều hành hoạt động toàn doanh nghiệp, có nhiều tên tuổi đáng kể NASA, Boeing, Airbus, Lockheed Martin, Rolls Royce, DaimlerChrysler, Ferrari, Toyota, Bose … Mỗi dự án triển khai Windchill cho doanh nghiệp kéo dài vào khoảng từ tháng đến 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 cài đặt thêm, performance tuning, administrator training, user training, chạy thử nghiệm chạy thức).[2] Từ năm nay, Công ty sản xuất hàng thể thao N cố gắng dử dụng Windchill làm cho hệ thống enterprise software mình, chi 35 triệu USD nhiều nhân tài vật lực vào dự án Bộ phận Sản xuất giày dép (Footwear Production) công ty N có phận IT riêng mình, để triển khai dự án, công ty thuê chuyên gia tư vấn Công nghệ thông tin để tiến hành Đây cách làm việc phổ biến Mỹ, việc phát triển phần mềm cài đặt hệ thống mang tính chất thời vụ, lại đòi hỏi trình độ chuyên môn cao Mặt khác, hệ thống hoàn thành, việc vận hành bảo trì đòi hỏi trình độ chuyên môn tương đối thấp Vì công ty sản xuất dịch vụ trì đội ngũ IT với trình độ vừa phải, lương thấp để bảo trì vận hành hệ thống, có nhu cầu làm mới, thuê chuyên viên tư vấn với giá cao, thời gian thực dự án Cách làm giúp cho công ty tiết kiệm chi phí hoạt động, bảo đảm tính chuyên môn hóa cao (Giả sử công ty thuê chuyên gia tư vấn tốt, tổ chức làm việc theo nhóm cách có hiệu quả) Trong quản lý dự án, công ty N sử dụng Quản trị dự án (Project Manager) nhân viên thức N (Permannent full time employee) Các nhân viên Dự án chia làm ba nhóm Nhóm Chuyên gia sản xuất giày dép (Domain expert – Trong trường hợp Những học từ dự án phần mềm này, domain footwear production, nhóm gọi Footwear Expert), Nhóm Phân tích Hệ thống kinh doanh (Business System Analyst) Nhóm Chuyên gia phần mềm (Application Engineer) Nhóm Chuyên gia sản xuất giày dép nhân viên thức công ty N, công việc hàng ngày thiết kế mẫu giày dép, giao dịch với nhà máy châu Á công ty cung cấp nguyên vật liệu khắp giới, người cung cấp thông tin quy trình, phương pháp logic làm việc 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 thông tin quy trình, phương pháp logic làm việc để xây dựng phần mềm tự động hóa công việc Trong nhóm này, vị trí Senior chuyên viên tư vấn, vị trí lập trình, có xen lẫn nhân viên tư vấn có kinh nghiệm nhân viên thức N Trong dự án phức tạp, đòi hỏi có giao tiếp chặt chẽ, xác nhóm cung cấp thông tin sản xuất, dịch vụ với nhóm làm phần mềm, thường có nhóm trung gian gọi Nhóm Phân tích Hệ thống sản xuất (Business System Analyst), đóng vai trò trao đổi thông tin Nhóm Domain Expert Nhóm Application Engineer Trong Công nghệ Phần mềm, thông thường chuyên gia sản xuất, dịch vụ Chuyên gia Phần mềm nhìn công việc hệ thống từ góc nhìn khác nhau, sử dụng thứ ngôn ngữ khác để mô tả hệ thống Do đó, chuyên gia nhóm Phân tích Hệ thống sản xuất phải vừa có kiến thức sản xuất lẫn kiến thức làm phần mềm (về độ am hiểu chuyên môn sâu không cần thiết phải nhóm Chuyên gia Sản xuất Chuyên gia Phần mềm, phải am hiểu khái niệm thuật ngữ) để làm trung gian hai nhóm Trong nhóm Phân tích Hệ thống sản xuất có chuyên viên tư vấn lẫn nhân viên thức công ty N Điểm yếu ba nhóm công ty N Nhóm Phân tích Hệ thống sản xuất Nhóm (hoàn toàn trái ngược với yêu cầu) khái niệm sản xuất giày lẫn sản xuất phần mềm Điều làm nảy sinh tình trạng hoạt động không hiệu quy trình quản lý quy trình làm phần mềm Những điểm yếu quy trình quản lý (Management Process) _ Công ty N phương pháp chuẩn (methodology) việc quản lý dự án phần mềm Dựa 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 làm specification, dựa vài mục đích, nhận định, công ty đưa số giới hạn thời gian, nhân lực, ngân sách, mà cụ thể Về mặt quản lý, công ty hoàn toàn phương pháp cụ thể việc phân chia trách nhiệm, quyền hạn nhóm thành viên nhóm Điều dẫn đến tình trạng có lúc công việc bị ách tắc sai lệch, không tìm nguyên nhân cách kịp thời, không quy trách nhiệm cho đối tượng cần phải sửa chữa có hình thức xử lý Những học từ dự án phần mềm Công ty hoàn toàn hệ thống hợp lý để theo dõi trình làm việc, theo dõi ngân sách tiến độ để điều chỉnh cho phù hợp Điều dẫn đến giai đoạn dự án thường xuyên bị chậmdead line vượt ngân sách dự tính Do Phương pháp thức (formal methodology) để đánh giá khả năng, trình độ tốc độ làm việc nhóm nhân viên dự án, đủ trình độ Chuyên môn Sản xuất giày dép Chuyên môn Công nghệ Phần mềm để nhận định lực kết làm việc thực nhân viên, nên Quản trị Dự án (Project Manager) Ban Lãnh đạo Dự án thu thập thông tin cách nói chuyện với nhân viên dự án để tìm hiểu nhân viên kia, họp với nhóm để lấy thông tin nhóm dự án, dẫn đến đánh giá chủ quan, cảm tính thường không xác Sự đời đâu thế, kẻ nói giỏi kẻ hay nói thường làm ăn không gì, thông tin thường sai lệch Vì Ban Lãnh đạo Dự án hoàn toàn nhận thức xác trình độ nhân viên, tiến trình dự án, không nắm bắt chi tiết thực xảy dự án Công ty N thực khâu tổ chức thực dự án cách máy móc Hàng tuần, 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 thứ năm để trao đổi thông tin nhóm Chuyên gia Sản xuất, Chuyên gia Phân tích Hệ thống Sản xuất Chuyên gia Phần mềm Ngoài nhiều họp phụ khác Một tuần làm việc có 40 tiếng, có vài lần phải tham gia họp 30 tiếng tuần, có vài ngày phải ngồi tiếng phòng họp Mặc dù có họp để báo cáo tiến độ công việc, thiếu phương pháp tốt để theo dõi, phân tích, đánh giá tình hình phân chia trách nhiệm, nên họp giúp cho Quản trị Dự án nhận làm được, lâu xong, mà sao, có cách làm nhanh không, đâu vị trí khó khăn thời điểm dự án… Cuộc họp xem xét thiết kế phần mềm tác dụng bổ ích mấy, công ty N tốn năm chi phí 35 triệu USD để xây dựng hệ thống phần mềm có nhiều vấn đề mặt thiết kế (tôi phân tích kỹ phần liên quan tới Kiến trúc phần mềm) Đại khái xây dựng, người ta vẽ thiết kế có vấn đề xây nên vài phần móng có vấn đề, việc xây thêm gia cố khómà dẫn đến kiến trúc thực tốt có giá trị sử dụng Vì thế, họp nhằm đưa giải pháp chắp vá, tạm thời để tạo chức có liệt kê danh sách mục đích xây dựng phần mềm Nhưng họp trao đổi thông tin nhóm làm việc thực thảm họa Có quy định máy móc Nhóm Chuyên gia Sản xuất nói chuyện với Nhóm Phân tích Hệ thống sản xuất, nhóm 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ì, phép nói Những học từ dự án phần mềm chuyện với Nhóm Chuyên gia Phân tích, nhóm hỏi Nhóm Chuyên gia Sản xuất truyền đạt lại Trong đó, nói, Nhóm Chuyên gia Phân tích lại bao gồm người khái niệm Sản xuất giày lẫn Sản xuất Phần mềm, nên Nhóm Phân tích đóng vai trò Nhóm đưa tin hai nhóm Chuyên gia Sản xuất Chuyên gia Phần mềm Hơn nữa, trình độ chuyên môn, nên nhóm Phân tích không đọc Use Case Diagram để trao đổi với nhóm Phần mềm, mà 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 thứ ngôn ngữ xác để trao đổi mặt phân tích yêu cầu, thu thập thông tin thiết kế hệ thống cho toàn dự án Ngoài ra, cách tổ chức trao đổi thông tin kỳ quặc: Trong thứ năm tuần, Nhóm Phần mềm họp với Nhóm Phân tích, bàn bàn lại hồi, rút có số vấn đề sau chưa biết Nhóm Phân tích đem vấn đề hỏi nhóm Sản xuất vào họp thứ năm tuần Và họp ngày thứ năm tuần tiếp sau nữa, Nhóm Phân tích đem câu trả lời cho Nhóm Phần mềm Như tuần cho câu hỏi trả lời, việc diễn năm nay, từ khu nhà Nhóm Phần mềm xuống Nhóm Sản xuất phút, tất nhân viên dự án có điện thoại e-mail Đó chưa kể đến thiếu hiểu biết chuyên môn 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ó vấn đề phải hỏi hỏi lại Có hai trường hợp điển hình Một lần có chuyên gia phần mềm hỏi “Trong thiết kế mẫu, người ta quản lý cỡ giày nào, theo giá trị xác (exact size, nghĩa số 5,6,7,8,9 ), hay theo khoảng cỡ (size-range, tức 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 câu trả lời cụ thể Chuyên gia phần mềm đành phải làm câu hỏi có nhiều chọn lựa (multi-choice question), gồm có a) Quản lý theo giá trị xác, b) Quản lý theo khoảng cỡ, c) Quản lý theo kiểu khác, đề nghị viết rõ, đưa cho Nhóm Phân tích hỏi Nhóm Sản xuất, đề nghị khoanh vào a b c, có câu trả lời a) Nếu quy định máy móc Nhóm Phần mềm không giao tiếp với Nhóm Sản xuất , Nhóm Phân tích biết chuyên môn biết sử dụng thuật ngữ, tình trạng không Trường hợp thứ hai có lần có chuyên gia phần mềm hỏi: “Về mặt quản lý vận tải, lần gửi hàng, có hàng hóa nhiều đơn đặt hàng gửi chuyến hay không?” Trước công ty N hệ thống theo dõi vận tải, giao dịch làm giấy tờ Thay hỏi trực tiếp người từ trước đến theo dõi việc vận tải sổ sách, Ban Quản trị Dự án họp đoán già đoán non, cho việc theo dõi nhiều đơn đặt hàng khác chuyến vận tải khó (?), nên cho phần mềm cần theo dõi chuyến vận tải đơn đặt hàng thôi, bất chấp ý kiếncủa Nhóm Phần mềm mặt công nghệ khó, ý kiến Nhóm Sản xuất trước có nhiều Những học từ dự án phần mềm trường hợp chuyến hàng chứa nhiều đơn đặt hàng Sau Nhóm Phần mềm cài đặt xong Hệ thống theo dõi Đơn đặt hàng Vận tải, công ty N cử nhóm người sang châu Á để đưa cho nhà máy châu Á sử dụng thử thu thập ý kiến phản hồi, nhận phải làm hệ thống theo dõi nhiều đơn đặt hàng khác chuyến vận tải Kết toàn công việc hai tháng trời phải bỏ hoàn toàn, làm lại từ đầu Một tượng khác điển hình cho thiếu Kiến thức lý thuyết lẫn Kinh nghiệm thực tế Quản lý Dự án phần mềm Ban Lãnh đạo Dự án 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ỳ nhân viên quản trị dự án phần mềm tập tọng vào nghề phải nghe qua định luật Brooks [3]: “Thêm người vào Dự án phần mềm bị chậm làm cho chậm hơn.” Định luật Brooks chứng minh mô hình toán học cách xác, kiểm nghiệm qua nhiều dự án phần mềm thực tế Những điểm yếu quy trình phát triển phần mềm (Software Development Process) _ Công ty N sử dụng Quy trình Phát triển phần mềm chuẩn Công nghệ Phần mềm Rational Unified Process (RUP) Hiện tại, ngành Công nghệ Phần mềm, đại đa số Dự án Phần mềm lớn phức tạp sử dụng RUP làm Quy trình Phát triển phần mềm Quy trình gồm có giai đoạn: Khởi đầu (Inception), Dự thảo chi tiết (Elaboration), Thực xây dựng (Construction), Chuyển giao (Transition) Trình bày chi tiết Rational Unified Process hoàn toàn không nằm khuôn khổ viết Nhưng quy trình tốt không bảo đảm cho thành công dự án phần mềm Phương pháp tiến hành bước giai đoạn dự án yếu tố quan trọng Trong toàn ba giai đoạn đầu dự án, công ty N phạm phải sai lầm Giai đoạn bốn (Transition) chưa có, chưa có sản phẩm thức đưa vào sử dụng, nên chưa có sai lầm Suốt năm từ lúc bắt đầu Dự án nay, sau tiêu tốn 35 triệu USD, công ty N đưa vài kết thử nghiệm: • Hệ thống Quản lý Vật liệu (Material Management) Nghe tên vậy, thực chất hệ thống cho phép ghi đối tượng vật liệu vào database, thêm, xóa, sửa, tìm kiếm …, nghĩa chức thông thường chương trình quản lý Những học từ dự án phần mềm • Hệ thống Quản lý màu sắc (Color Management) : Đây hệ thống cho phép thêm, xóa, sửa, tìm kiếm màu sắc database • Hệ thống quản lý Dự án (Project Management), thực hệ thống tạo thêm, xóa, sửa, tìm kiếm tài liệu cho dự án, quản lý tiến trình (workflow management) theo dõi tiến độ dự án (project progress tracking), giai đoạn chạy thử nghiệm có đầy lỗi * Giai đoạn Khởi đầu (Inception) : Đây giai đoạn dùng để thu thập thông tin, nhằm đặt mục đích tầm mức Dự án Phần mềm Thay thu thập trực tiếp thông tin thực thiết kế sản xuất giày để xây dựng tầm mức mục đích, công ty N chọn cách thu thập chức mục đích cho chương trình cách chép lại toàn chức mục đích hệ thống phần mềm cũ (legacy system) chạy mainframe, hệ thống cũ làm Power Builder SAP Đây sai lầm ấu trĩ, legacy system kể xây dựng cách hàng chục năm, dựa công nghệ lạc hậu, không thông qua quy trình thiết kế phân tích chuẩn cho hệ thống Hướng đối tượng (Object Oriented), thời chưa có công nghệ Hơn nữa, quy trình thiết kế sản xuất giày dép việc trao đổi thông tin 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 chi nhánh quy trình sản xuất hoàn toàn thay đổi Chính thế, định việc xây dựng hệ thống phần mềm với công nghệ để chép hoàn toàn chức hoạt động hệ thống phần mềm cũ sẵn có, với bổ sung, phi lý, thiếu thực tế, xét cho cùng, việc giữ nguyên hệ thống cũ để sử dụng có giá trị thực tiễn kinh tế cao * Giai đoạn Dự thảo chi tiết (Elaboration): Trong giai đoạn này, thông tin thu thập giai đoạn Khởi đầu (Inception) đánh giá phân tích chi tiết, nhằm xác định cụ thể, thức tầm mức dự án (project’s scope) , yêu cầu dự án (project’s requirement), điều kiện để dự án coi hoàn thành (project’s acceptance criteria), tính dự án (project’s feature) tính quan trọng (critical criteria), xác định mạo hiểm xảy (potential risk), xác định chi tiết thực tế sản xuất (business specification) để dẫn tới xây dựng chi tiết thiết kế phần mềm (design specification) 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ợ 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ụ thực giai đoạn Một sai lầm giai đoạn cụ thể hóa dự án Ban Lãnh đạo Dự án đánh giá sai thời gian khối lượng công việc việc chuyển đổi database từ hệ thống cũ (legacy system) dùng mainframe, Power Builder SAP sang Oracle database Windchill Những học từ dự án phần mềm Không hiểu vào đâu, dựa tiêu chí nào, vào phân tích sao, mà Ban Lãnh đạo Dự án xác định để chuyển đổi database từ hệ thống cũ sang Windchill’s Oracle database phải tốn năm Điều chứng tỏ Ban Lãnh đạo Dự án khái niệm database migration Hệ thống cũ chạy Power Builder SAP dùng Oracle database, nghĩa hoàn toàn truy cập từ chương trình Java Có liệu lưu khu vực lưu trữ riêng Power Builder App SAP, có công cụ kết nối (adapter), đọc từ chương trình Java Như công việc chuyển đổi database từ legacy system sang Windchill bao gồm phần việc sau: Xác định database schema data format legacy system Xây dựng database schema cho hệ thống Windchill’s Oracle database Viết chương trình đọc database từ legacy system ghi vào Windchill’s database Đây công việc bản, lặp lặp lại cho tất dự án có chuyển đổi database (database migration) Bất kỳ Kiến trúc sư Phần mềm (Software Achitect) có kinh nghiệm với nhóm lập trình viên trình độ trung bình hoàn thành Dự án database migration khoảng tháng đến năm Rất nhiều dự án database migration nhà máy sản xuất máy bay chiến đấu, tàu ngầm hạt nhân, ô tô đua … (là thứ phức tạp giày nhiều) thực với thời gian ngắn Chính nhận định sai thời gian chuyển đổi database, nên Ban Lãnh đạo Dự án đề mục đích tầm mức kỳ quặc cho dự án Dự án xây dựng chương trình sử dụng Java, J2EE Windchill để cung cấp giao diện database cho Hệ thống quản lý sản xuất giày có chức giống hệt Hệ thống cũ viết Power Builder, với vài chức không đáng kể, ví dụ theo dõi Vận tải Đơn đặt hàng Phần phối hợp chức hoạt động phận, tạo vài loại đối tượng định, dùng Hệ thống cũ viết Power Builder SAP, gửi liệu qua Windchill Dần dần, sau thời gian chạy thử vào khoảng đến 10 năm, hệ thống xây dựng dựa Windchill đưa vào thay hoàn toàn hệ thống cũ Sự sai lầm nhận định mục đích tầm mức là: Windchill có sẵn toàn chức để phối hợp hoạt động sản xuất kinh doanh phận khác (vì nên gọi PDM/PLM Collaborative enterprise software) Quyết định dùng Windchill để làm giao diện lưu trữ liệu, dùng hệ thống cũ để Những học từ dự án phần mềm phối hợp hoạt động (mặc dù công nghệ hệ thống cũ lạc hậu, lỗi thời đủ chức năng) định hiểu Hơn nữa, theo tiến trình phát triển công nghệ nay, khoảng đến 10 năm nữa, công nghệ hoàn toàn thay đổi, Hệ thống xây dựng dựa J2EE trở nên lỗi thời Chả lẽ lúc lại tiến hành xây dựng hệ thống mới, lúc việc chuyển đổi chức năng, liệu Hệ thống Power Builder + SAP với Hệ thống Windchill chưa xong, sử dụng song song hệ thống hay 10 năm tiếp sau nữa? Những nhận định kế hoạch nói chứng tỏ Ban Lãnh đạo Dự án thiếu thực tế mặt Sản xuất khái niệm Quản lý Tiến hành Dự án Phần mềm Khâu chuẩn bị vật chất công cụ cho dự án tiến hành Mạng máy tính công ty N vào năm 1999 bị hacker công lần, tai tiếng lớn, nên công ty trở nên đa nghi an ninh mạng (network security), thiếu khả năng, nên cài đặt nhiều công cụ security tự động lên mạng máy tính cá nhân, làm cho mạng máy tính trở nên chậm ổn định Rất nhiều lập trình viên ngày đẹp trời tự nhiên thấy máy tính bị loại khỏi domain N network, phải gọi quản trị mạng để kết nối trở lại Máy tính dùng hệ thống mua hãng danh tiếng, có lẽ loại rẻ, dùng cho gia đình, chưa qua test để dùng công nghiệp, nên có nhiều máy tính bị hỏng, nguy hiểm hỏng đĩa cứng, toàn liệu Về môi trường phát triển phần mềm (software development environment), công ty sử dụng nhiều công cụ chuẩn (standard tool) sử dụng rộng rãi Công nghệ Phần mềm nhiều công ty khác, đáng tiếc lại sử dụng sai, nên phát sinh nhiều cố trình phát triển phần mềm Một ví dụ điển hình để kiểm soát mã nguồn (source code control) chia sẻ làm việc theo nhóm, công ty sử dụng ClearCase, công cụ quản lý mã nguồn mạnh công ty Rational Software Nhưng đáng tiếc công ty không thuê chuyên gia cài đặt định cấu hình ClearCase có đủ trình độ, nên việc quản lý mã nguồn dự án luôn gặp trục trặc, chương trình không dịch được, ClearCase view update chuyện bình thường Chương trình dùng để viết Java code Dự án Eclipse, opensource IDE phổ biến, có nhiều chức công cụ mạnh, mã nguồn dự án project tổ chức File System phức tạp, nên việc setup Eclipse Project để viết chạy chương trình đòi hỏi phải qua nhiều bước phức tap, 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) phát sinh lệnh SQL để tạo table database (SQL generation) thực UML diagram Rational Rose Nhưng cách cài đặt (setup) định cấu hình (configure), nên lần thay đổi mô hình (model), lập trình viên lại trải qua thời gian dài đau khổ trước database hoạt động chương trình chạy trở lại Có nhiều lập trình viên đến công ty chơi tuần máy tính hỏng, để làm, máy tính để thay Hiện nay, công ty thuê vài nhân viên tư vấn để Những học từ dự án phần mềm chuyên nghiên cứu việc cài đặt môi trường phát triển (setup development enviroment), tình hình cải biến cách chậm chạp, project tiến hành năm * Giai đoạn Thực xây dựng (Construction): Trong giai đoạn này, sai lầm có tính chất định sai lầm Kiến trúc phần mềm (Software Architecture) Những sai lầm phân tích chi tiết phần Những điểm yếu Kiến trúc Phần mềm Trong phần này, tập trung phân tích sai lầm việc cài đặt phần mềm, không liên quan đến kiến trúc Ban Lãnh đạo Dự án công ty N chọn quy trình phát triển phần mềm theo mô hình Iterative Development, mô hình phổ biến phát triển phần mềm Nhưng Ban Lãnh đạo Dự án hiểu sai toàn ý nghĩa Iterative Development Iterative Development chia trình xây dựng phần mềm làm nhiều khoảng thời gian nhỏ gọi iteration Trong iteration đó, có đủ bốn giai đoạn RUP Khởi đầu (Inception), Dự thảo chi tiết (Elaboration), Thực xây dựng (Construction) Chuyển giao (Transition) Toàn Hệ thống phần mềm chia nhỏ thành chức nhóm chức năng, đủ để thực thời gian iteration Trong khoảng thời gian iteration, chức (hoặc nhóm chức năng) phải hoàn thành đưa qua đủ giai đoạn kể trên, phân tích, thiết kế cho thành phần phần mềm Hệ thống phát triển, thay đổi đánh giá lại, kết kết thúc iteration, có thêm phần Dự án hoàn thành Trải qua nhiều iteration, hệ thống phần mềm hoàn thành Phát triển theo mô hình Iterative Development cho phép bổ sung thêm thông tin thực tế, thay đổi thiết kế chỉnh sửa việc cài đặt chức cho chức nhóm chức năng, mà không làm ảnh hưởng ảnh hưởng đến tiến trình toàn Dự án phần khác Hệ thống Nhưng iteration Dự án công ty N thực sau: Cả hệ thống chia làm nhiều chức (hoặc nhóm chức năng) nhỏ Sau đó, việc phân tích qua loa đại khái, chưa có đủ thông tin bắt tay vào việc thiết kế lập trình Sau hoàn thành việc lập trình cho chức (hoặc nhóm chức năng) này, nhiên trình thu thập thông tin, phân tích có thêm thông tin, thiết kế thay đổi, lại vứt bỏ toàn từ mô hình đối tượng (object model), Java code database schema, viết lại từ đầu iteration Kết trải qua nhiều iteration, có phần Dự án hoàn thành, thời hạn 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 nhắc lại bắt đầu iteration “Chúng ta lùi hai bước để tiến lên ba bước”, thực tế lùi hai bước tiến lên hai bước (vì kết thúc iteration mới, có chức iteration cũ cài đặt lại mà thôi), trình diễn lặp lặp lại nhiều lần Những học từ dự án phần mềm Windchill gọi Modelled Attributes (Các thuộc tính mô hình hóa), tất Business Object mô hình hóa (model) Java Object, sử dụng tất lớp (layer) từ Windchill Service đến Presentation IBA (International Business Attribute) component kiến trúc phần mềm, mà hệ thống công cụ để chuyển đổi hệ thống đo lường Anh-Mỹ Quốc tế Do đó, gọi Modelled Attributes IBA nằm Command Delegate Windchill Services Thứ hai lớp Windchill Services Oracle Database có lớp Persistence Layer, làm nhiệm vụ chuyển đổi Java object Relational Database (Object-Relational Mapping – ORM), đồng thời đóng vai trò tìm kiếm (query) thao tác (manipulate) database Sai lầm từ xuất phát điểm dự án không sử dụng hết chức sẵn có Windchill Hệ thống Windchill cung cấp toàn tính cần thiết hệ thống PDM/PLM Enterprise Software bao gồm chức 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ạng dịch vụ (service) framework mở rộng Nhưng Dự án triển khai Windchill công ty N sử dụng phần giới hạn chức Windchill: • Chức mô hình hóa đối tượng (object modelling), mô hình hóa dịch vụ (service modelling), phát sinh mã chương trình Java từ mô hình (Java code generation from model) 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 để ghi object vào database, đọc object từ database xóa object database Không sử dụng chức database query database manipulation • Sử dụng phần nhỏ LifeCycle Management để đổi trạng thái (State) object database • Sử dụng RMI server Windchill để làm giao tiếp RMI client server • Sử dụng Windchill configuration cho Apache Webserver, Tomcat Aphelion LDAP server để dùng phần nhỏ Directory Service Authentication Như vậy, chức enterprise software Windchill object versioning, data transportation, workflow management, built-in business object , advanced query capabilities, data replication, security access control hoàn toàn không sử dụng Những học từ dự án phần mềm Do thiếu hiểu biết kiến trúc chức Windchill, nên cần có chức sơ đẳng bản, Nhóm Phần mềm Dự án phải làm từ đầu, phát minh lại nhiều bánh xe, thiếu hiểu biết, nên thành phần (component) làm việc không tốt với Windchill foundation, nhiều thành phần có tốc độ thi hành chậm (slow performance) Một ví dụ điển hình phát minh lại bánh xe dự án N Search Framework Windchill Foundation cung cấp Persistence Layer hoàn chỉnh, với toàn chức database query database manipulation từ đến nâng cao, bao gồm hết toàn chức SQL’92 phần mở rộng Oracle SQL, phiên 8i 9i Nhưng hoàn toàn cách sử dụng, Kiến trúc sư Phần mềm (Software Architect) Ban Lãnh đạo Dự án định xây dựng gọi N Search Framework, dùng để tìm kiếm đối tượng database Từ N Search Framework đời, cần tìm kiếm đối tượng database, thay viết code khoảng phút sử dụng Persistence Layer, lập trình viên phải dùng Rational Rose để tạo mẫu (model) cho loại đối tượng khác nhau, viết lớp đối tượng Search Criteria Search Result cho client side viết code cho lớp đối tượng Java server side, cập nhật (update) file cấu hình XML (XML configuration), ngày làm việc (8 tiếng) Việc tìm kiếm đối tượng database trở nên phức tạp có kiểu đối tượng mới, phải dành hẳn lập trình viên làm việc ngày để viết code cho việc ghi đối tượng vào database tìm kiếm đối tượng Ngoài ra, hệ thống software N hoàn toàn security access control, sau qua basic authentication với Webserver thực tất lệnh với tất đối tượng hệ thống Không thiếu hiểu biết enterprise software Windchill, Kiến trúc sư phần mềm (Software Architect) Ban lãnh đạo Kỹ thuật Dự án tỏ thiếu hiểu biết toàn diện Phân tích/Thiết kế Hướng đối tượng (Object Oriented Analysis/Design – OOA/OOD) Lập trình Hướng đối tượng (Object Oriented Programming – OOP) Về mặt phân tích (Analysis), tất thực thể (entity) tham gia vào trình sản xuất User Story tạo object tương ứng Hệ thống Phần mềm Điều sai lầm sơ đẳng học sinh học lập trình, tất thực thể kể quy trình sản xuất đối tượng phần mềm, mà có số định đối tượng (business object), số mối quan hệ đối tượng (object relationships) số thuộc tính đối tượng (attributes of objects) Tất nhiên, Object Oriented Analysis/Design tương tự Kiến trúc Xây dựng, câu trả lời tuyệt đối đúng, mà có câu trả lời tốt hơn, nằm ranh giới nghệ thuật (Art) nhiều nằm ranh giới Kỹ thuật (Engineering) Nhưng thu thập thông tin sản xuất, dịch vụ, có thực thể (entity) quy object hệ thống phần mềm sai lầm ấu trĩ tha thứ Những học từ dự án phần mềm Sau vài năm, sau có khái niệm mối quan hệ đối tượng (object relationships) mối liên kết đối tượng (object-to-object link), Kiến trúc sư Phần mềm lại tỏ hăng hái việc tạo object-to-object link có nhiều business object tạo mẫu (model) hệ thống link Một sai lầm khác phân tích (OOA) không xác định Tính Tối thiểu Và Đủ xây dựng đối tượng Một ví dụ Tính Tối thiểu Đủ: Giả sử Hệ thống theo dõi Chuyên môn, có lớp đối tượng Programmer, thuộc tính mà hệ thống cần phải biết Lập trình viên Tên, Bằng cấp, Trình độ Lập trình, Những kỹ chuyên môn, Khả đặc biệt, Số năm kinh nghiệm, Quá trình làm việc (Tùy theo hệ thống theo dõi Chuyên môn, có vài thuộc tính nữa, với mục đích ví dụ, giới hạn thuộc tính đề cập trên) Tất nhiên, ông lập trình viên A khác ông lập trình viên B chỗ ông béo, ông gầy, ông người Ấn Độ ông người Mỹ, ông lái xe màu đỏ, ông lái xe màu xanh… Nhưng thuộc tính Béo-Gầy, Ấn Độ – Mỹ – Xe màu đỏ – Xe màu xanh … thuộc tính tiêu biểu cho việc theo dõi Chuyên môn , nên không lưu trữ lớp Programmer (Nhưng để mục đích theo dõi cá nhân, lưu trữ lớp đối tượng Employee, có) Như vậy, tập thuộc tính Tối thiểu Đủ cho lớp Programmer (Tên, Bằng cấp, Trình độ Lập trình, Những kỹ chuyên môn, Khả đặc biệt, Số năm kinh nghiệm, Quá trình làm việc ) Nhưng không xác định tính Tối thiểu Đủ, nên đối tượng dự án N thường có thuộc tính chồng chéo, có nhiều lớp đối tượng có quan hệ với nhau, tham khảo lòng vòng đối tượng, có nhiều thuộc tính đặt sai vị trí Ví dụ thuộc tính đặt sai vị trí: ví dụ lề trên, thuộc tính quốc tịch không đặt lớp Employee, mà đặt lớp Programmer Một sai lầm thô thiển khác không phân biệt lớp đối tượng (object class) thể đối tượng (object instance) Ví dụ ta nói đến xe ô tô, tức ta nói đến lớp (class) xe ô tô nói chung, ta nói đến ô tô BMW có biển đăng ký XYZ 123, tức ta nói đến xe xác cụ thể, thể (instance) lớp đối tượng ô tô Chính không phân biệt khái niệm class instance, Hệ thống Phần mềm công ty N có trường hợp đặc biệt ấu trĩ như: • Trong hệ thống 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ó thuộc tính giống hệt Đúng ra, tất vật thể (entity) And, Or, Xor, Not kể thuộc lớp đối tượng (class) gọi Toán tử (Operator), chúng thể (instance) có tên khác And, Or, Xor, Not • Trong hệ thống có lớp đối tượng Mũi giày, Đế giày, Dây giày, Thân giày … Đúng tất vật thể (entity) kể thuộc lớp đối tượng gọi Chi tiết Giày (ShoePart) có tên gọi khác Những học từ dự án phần mềm Một máy bay có hàng chục triệu chi tiết khác nhau, Hệ thống Phần mềm cho Sản xuất máy bay Boeing, Airbus hay Lockheed Martin cài đặt theo phân tích thiết kế công ty N, Hệ thống phải có hàng chục triệu kiểu đối tượng (object type), để viết code cho đối tượng phải vài nghìn năm, chưa nói đến chuyện viết code cho hệ thống Công nghệ Hướng đối tượng (Object Oriented Technology) có ưu điểm có công cụ để xây dựng 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) dễ phát triển, mở rộng (easy to extend) thành phần tự nhiên mà có, mà phải thông qua trình phân tích kỹ lưỡng, phải thiết kế cách hợp lý, có tính toán sâu sắc tầm nhìn xa Điều phụ thuộc vào quy trình, phương pháp làm việc trình độ Kiến trúc sư phần mềm, điều sẵn có Công nghệ Hướng đối tượng Có vẻ Kiến trúc sư phần mềm (Software Architect) Lãnh đạo Kỹ thuật dự án công ty N biết đến từ ngữ reuse, extensible qua sách Nhập môn Lập trình, kiến thức thực tế, nên thuật ngữ sử dụng vung vít tài liệu thiết kế họp, thành phần hệ thống sử dụng lại được, dễ dàng mở rộng Một ví dụ điển hình thiết kế 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 định kiểu đối tượng ShipmentInfo sử dụng (reuse) cho việc quản lý gửi hàng cho nhiều loại đối tượng khác nhau, không riêng cho Đơn đặt hàng, đối tượng ShipmentInfo thông tin Đơn đặt hàng Thế ShipmentInfo đối tượng để quản lý Vận tải, tức phải có nội dung hàng hóa giửi chuyến gửi hàng Thông tin gửi hàng mà không nói lên gửi sử dụng vào đâu? Sau thời gian họp hành lâu, Ban Lãnh đạo Dự án nhận điều hiển nhiên Thay dùng kiểu giao diện tổng quát (generic interface) gọi ShipmentContent để chứa thông tin nội dung gửi ShipmentInfo, cài đặt đối tượng cụ thể gửi Hóa đơn Vận tải Đơn đặt hàng, Mẫu tiếp thị , Hàng bán Chính thức implementation interface ShipmentContent, ShipmentInfo sử dụng lại để quản lý Vận tải cho tất lớp đối tượng có cài đặt (implement) ShipmentContent interface, Kiến trúc sư phần mềm Ban Lãnh đạo định dùng nhiều liên kết (link) lòng vòng để diễn tả thông tin mối quan hệ Hóa đơn Vận tải, Hàng gửi Địa gửi hàng, làm tăng đáng kể độ phức tạp thao tác bản, lẽ phải đơn giản ghi Hóa đơn Đơn đặt hàng vào database đọc Hóa đơn Đơn đặt hàng từ database Và cuối cùng, thực mối liên kết thông qua link phức tạp có mối ràng buộc cao hơn, nên đối tượng ShipmentInfo chẳng reuse vào đâu Những học từ dự án phần mềm Việc thiết kế kiểu đối tượng cách bừa bãi, kiểu đối tượng tương ứng với thực thể thực tế, phân loại đối tượng có nhóm chức năng, có giao diện chung, làm cho kiểu đối tượng dùng cho trường hợp cụ thể Hệ thống, tính sử dụng lại (reuse), lần cần mở rộng, bổ sung chức có cách mở file Java code 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) Ban Lãnh đạo Dự án tỏ có hiểu biết nông cạn ấu trĩ Số lượng Mẫu thiết kế (Design Pattern) áp dụng vào dự án hạn chế, thường áp dụng sai, với yêu cầu đặc điểm dự án, thiết kế hệ thống hoàn toàn rơi vào đại đa số trường hợp điển hình để áp dụng Mẫu thiết kế (Basic Design Pattern) Mẫu thiết kế J2EE (J2EE Design Pattern) Có hai trường hợp áp dụng Design Pattern cách tương đối Business Delegate Singleton Design Pattern, có ví dụ sẵn Windchill foundation [4] Trong Windchill foundation có nhiều ví dụ khác áp dụng Design Pattern, thiếu kiến thức Windchill không đọc Windchill document Windchill code, nên thiết kế Dự án không áp dụng Trong đó, ví dụ áp dụng sai Design Pattern nhiều không kể xiết Sai lầm phải kể đến áp dụng sai MVC Design Pattern [5], design pattern mà học nhập môn Lập trình Hướng đối tượng phải biết Mục đích MVC Design Pattern nhằm để tách biệt liệu (data) phần hiển thị liệu (view) Như vậy, đối tượng lưu trữ liệu logic mặt hiển thị (presentation logic), đối tượng hiển thị liệu (view) chủ yếu sử dụng getters đối tượng liệu (model) để lấy thông tin cần hiển thị Trong đó, Dự án, đối tượng tạm gọi Client Object lại có chứa chức hiển thị, việc notify GUI component việc thay đổi giá trị vài chức khác, đó, đối tượng View Model bị phụ thuộc chặt chẽ vào Do sử dụng sai MVC Design Pattern, chèn logic hiển thị vào đối tượng mang liệu, nên đối tượng mang liệu để hiển thị khác với business object tạo lưu trữ database Như vậy, hệ thống có hai loại đối tượng để biểu diễn cho liệu Client Object Business Object (ví dụ, để biểu diễn mẫu giày, ta có ClientShoe BusinessShoe, ClientShoe sử dụng client side BusinessShoe sử dụng server side) Do đó, cần thông tin business object (ví dụ Mẫu giày hay Đơn đặt hàng), cần phải có trình chuyển đổi từ Business Object sang Client Object Trong tất phần Dự án, cần ghi Business Object tạo từ Client GUI vào database, tốn khoảng dòng code để ghi Business Object vào database, kể khởi tạo transaction, phải tốn kèm vào khoảng 100 dòng code để copy thuộc tính từ Những học từ dự án phần mềm Client Object sang Business Object (Đây có cải tiến sau loại bỏ Data Transfer Object) Do có nhu cầu gửi thông tin lớp (layer) khác Hệ thống, Kiến trúc sư Phần mềm Dự án nảy sinh ý định sử dụng Design Pattern Data Transfer Object (DTO) DTO Design Pattern sử dụng để truyền thông tin lớp (layer) khác hệ thống phần mềm nhiều lớp (multi-layer system), dùng trường hợp sau đây: • Dùng để gửi nhiều thông tin rời rạc lần gửi (Ví dụ để gửi username password từ cửa sổ login tới authentication service để kiểm tra, thay gửi hai String riêng biệt username password, hai lần communication qua layer, chương trình đóng gói username password thành thuộc tính đối tượng AuthenticationInfo gửi đối tượng đi, tốn lần communication) • Dùng để làm giảm số lần giao tiếp từ xa (remote request) mạng Nhiều thông tin (nhiều thuộc tính nhiều đối tượng) đóng gói vào đối tượng Data Transfer Object gửi qua thành phần phân tán (distributed component) mạng, làm giảm số lần trao đổi qua lại mạng, làm giảm network traffic tăng application performance Ví dụ client có yêu cầu cần biết Đơn đặt hàng (Sample Request) Thông tin Vận tải (ShipmentInfo) Đơn đặt hàng, thay gửi Sample Request ShipmentInfo hai lần gọi API qua mạng, hệ thống đóng gói Sample Request ShipmentInfo vào DTO object gửi lần gọi API qua mạng (Đáng tiếc hệ thống công ty N không thiết kế vậy) Trong dự án công ty N, DTO Design Patter sử dụng sau: Bởi có hai loại đối tượng khác biểu diễn cho liệu Client Object client side Business Object server side, nên để truyền liệu từ client side đến server side ngược lại, hệ thống sử dụng loại đối tượng thứ ba gọi Data Transfer Object (DTO) Như vậy, hệ thống, tương ứng với loại liệu có loại đối tượng khác Client Object client side, Business Object server side DTO Object dùng để gửi thông tin client server Ví dụ mẫu giày có ClientShoe, BusinessShoe DTOShoe Quá trình ghi mẫu giày thiết kế từ GUI vào database tiến hành sau: • Tại client side: Copy thuộc tính (attributes) từ ClientShoe vào DTOShoe • Gửi DTOShoe tới server • Tại server side: Copy thuộc tính từ DTOShoe vào BusinessShoe Những học từ dự án phần mềm • Ghi BusinessShoe vào database Việc áp dụng DTO Design Pattern không làm giảm số lượng thông tin rời rạc gửi từ client tới server, thông tin ClientShoe DTOShoe mặt DTO trường hợp không làm giảm số lần communication qua mạng, dù gửi ClientShoe hay gửi DTOShoe từ Client đến server tốn lần gửi đối tượng Ngược lại, áp dụng DTO trình bày tăng thêm 100 dòng code để copy thuộc tính từ ClientShoe sang DTOShoe 100 dòng code để copy từ DTOShoe sang BusinessShoe Sau năm tìm tòi, nghiên cứu cách cần cù gian khổ, có lẽ nhận ngu xuẩn việc áp dụng DTO Design Pattern cách sai lầm mình, Kiến trúc sư Phần mềm Ban Lãnh đạo Dự án định loại bỏ DTO Object, gửi thẳng Client Object đến server side để copy sang Business Object Việc làm Ban Lãnh đạo Dự án đánh phát kiến vĩ đại, bước đột phá để tăng suất lập trình (Programming Productivity), cho kiểu đối tượng, bớt 100 dòng code phải viết, tăng tốc độ thi hành chương trình (Program Performance), bớt 100 dòng code phải thi hành Nhưng bỏ DTO lại phát sinh vấn đề lúc ClientObject có mang client code logic hiển thị (presentation logic) gửi tới server code, mà xuyên qua nhiều layer, đến tận Persistence Layer Điều phá vỡ hoàn toàn linh hoạt (flexibility) kiến trúc phần mềm nhiều lớp (multi-layer architecture), làm cho client server bị ràng buộc chặt chẽ (tightly-coupled) vào Một thay đổi nhỏ client code dẫn đến thay đổi nhiều lớp server code, từ business layer đến persistence layer nhiều trường hợp, chí thay đổi database schema Thiết kế thiên tài công ty N đưa lại năm 70 kỷ 20 với kiến trúc phần mềm lớp (2-tier) client-server, Lập trình có cấu trúc (Structural Programming) gọi hàm từ xa (Remote Procedure Call) Đồng thời phụ thuộc server vào client code thông qua việc sử dụng Client Object server code làm cho nhiều trường hợp, việc phát triển song song server code client code thực được, lập trình viên cho server code phải ngồi chơi, chờ đến lập trình viên cho client code hoàn thành việc lập trình cho Client Object Do quản lý yếu thiếu phối hợp Dự án, có nhiều trường hợp, lập trình viên cho client code viết code cho cửa sổ, menu đối tượng GUI trước viết code cho Client Object, lập trình viên cho server code hưởng niềm vui ngồi chờ lâu Một Giải pháp tốt cho tình trạng thiết kế Client tốt, tuân thủ chặt chẽ MVC Design Pattern, tức presentation logic data model Như vậy, Business Object sử dụng biểu diễn cho loại liệu hệ thống, từ Persistence Layer tới Business Layer Presentation Layer Business Object dùng để Những học từ dự án phần mềm gửi thông tin đối tượng lớp (layer) hệ thống, dùng làm model hệ thống MVC GUI Ngoài ra, không phân biệt Design Patterns Delegate, Template Strategy, khái niệm cài đặt sử dụng cách lung tung, bừa bãi dẫn đến cài đặt rắc rối, phức tạp (overly complicated implementation), dẫn đến khó bảo trì, phát triển làm chậm tốc độ chạy chương trình Ở vài ví dụ nhiều trường hợp sử dụng sai Design Pattern Software Architecture công ty N Hiểu biết nguyên tắc Lập trình Hướng đối tượng (OOP Fundamentals) Ban Lãnh đạo Dự án không so với hiểu biết OOA/OOD Những sai lầm OOP Fundamentalstrong dự án có nhiều, dẫn vài ví dụ điển hình Có hiệu mà lập trình viên tập việc có đọc qua lần “Code to interfaces, not code to concrete implementations”, nghĩa “Lập trình gọi đến giao diện, không gọi đến lớp cài đặt cụ thể.” Mục đích việc làm để tách riêng chức (functionality) khỏi cài đặt cụ thể (implementation) Điều có nghĩa thành phần (component) lớp (layer) hệ thống phần mềm giao tiếp với thông qua hệ thống chức năng/dịch vụ định nghĩa trước, việc cài đặt chức năng/dịch vụ phụ thuộc vào lớp cài đặt cụ thể (concrete implementation) Tuy nhiên, lớp cài đặt cụ thể không bộc lộ (expose) khỏi component layer, nên cách cài đặt thuật toán cho chức thay đổi, component layer khác hoàn toàn không bị ảnh hưởng, ảnh hưởng Điều làm tăng tính sử dụng lại, dễ bảo trì dễ phát triển component hệ thống [6] Nhưng (hoặc không hiểu) hiệu này, nên Hệ thống công ty N, hệ thống có định nghĩa interface, hàm API để giao tiếp lớp (layer) thành phần (component) hệ thống chủ yếu sử dụng lớp cụ thể (concrete class) tham số (parameters, arguments) giá trị trả (return value) Một sai lầm khác OOP Fundamentals dự án công ty N không phân biệt Mở rộng chức cho đối tượng Inheritance (Kế thừa) Mở rộng Composition (tạm dịch Bao gồm) Mở rộng Design Pattern (ví dụ Decorator Pattern Visitor Pattern), đó, tất phần dự án, việc mở rộng, bổ sung chức cho lớp đối tượng thực cách Inheritance, tạo họ (family) Những học từ dự án phần mềm lớp đối tượng lớn, thành viên thực chất chả có liên quan đến mấy, mà tạo nhu cầu mở rộng chức năng.[7] Trong hệ thống enterprise software, XML đóng vai trò quan trọng Và dự án công ty N, việc sử dụng XML có nhiều sai lầm, bao gồm Lạm dụng XML (Overuse XML) Sử dụng không hếtchức XML (Underuse XML) Trình bày chức phương pháp sử dụng XML Enterprise Software Development hoàn toàn không nằm phạm vi viết Tôi xin dẫn vài sai lầm việc sử dụng sai lầm dự án công ty N Một sai lầm nghiêm trọng sử dụng XML dự án đa số file XML viết trình phát triển dự án hoàn toàn biểu diễn cấu trúc kiểm tra cấu trúc thông qua DTD (Document Type Definition) XSD (XM Schema Definition) Điều dẫn đến tình trạng nguy hiểm cấu trúc file XML bị thay đổi cách bừa bãi, dẫn đến việc hệ thống hoạt động sai, sinh lỗi thi hành (run-time error) nghiêm trọng Trường hợp điển hình việc lạm dụng XML xảy việc xây dựng hàm tiện ích server side có tên getServerObject để tìm kiếm Business Object database biết kiểu đối tượng ClientObject Unique Identification object vào thời điểm mà hàm API gọi Như trình bày phần trên, cho kiểu liệu định, có hai kiểu đối tượng tương ứng ClientObject BusinessObject Quan hệ ClientObject ServerObject quan hệ 1:1, điều có nghĩa vào thời điểm hàm getServerObject gọi, ta biết kiểu đối tượng (object type) ClientObject, có nghĩa ta biết kiểu BusinessObject, việc gọi lệnh tìm kiếm database cho BusinessObject Tuy nhiên, theo yêu cầu Kiến trúc sư Phần mềm (Software Architect) Ban Lãnh đạo Dự án, nhằm mục đích tăng tính linh hoạt hệ thống (?), vào lúc gọi hàm getServerObject, biết rõ kiểu ClientObject, ta phải giả vờ kiểu BusinessObject, phải tìm XML mapping file để xem kiểu (type) BusinessObject gì, gọi lệnh tìm kiếm database cho BusinessObject Ở đây, việc tồn XML file XML lookup hoàn toàn thừa làm giảm tốc độ thực chương trình Trường hợp điển hình không sử dụng hết chức XML nằm N Search Framework dùng để tìm kiếm object database Như trình bày trên, framework hoàn toàn thừa, tạo nhiều rắc rối cho lập trình viên nhiều tạo công cụ Framework vấn đề mặt chức năng, mà có nhiều vấn đề mặt cài đặt Một vấn đề là: Đối với loại đối tượng (object type) khác nhau, cần phải có nhiều loại đối tượng phụ trợ (helper object) kèm thực việc tìm kiếm Và riêng hàm API phục vụ cho việc tìm kiếm, loại đối tượng phải có hàm getObject khác nhau, khác biệt hàm getObject loại đối tượng khác là: Những học từ dự án phần mềm • Thêm thuộc tính (attribute) làm điều kiện tìm kiếm cần lấy từ database vào danh sách thuộc tính • Lấy giá trị (value) thuộc tính đối tượng từ kết trả Các bước tiến hành khác hàm API getObject giống hệt Như dùng file XML để lưu thuộc tính làm điều kiện tìm kiếm thuộc tính cần lấy từ database cho loại đối tượng Sau viết hàm getObject cho tất loại đối tượng (object type), kiểu đối ượng truyền làm tham số cho hàm getObject, hai phần khác biệt kể trên, chương trình vào tham số object type để phân tích file cấu hình XML tìm điều kiện tìm kiếm thuộc tính trả cho loại đối tượng thích hợp Nhưng đáng tiếc, cài đặt N Search Framework, có hàng chục hàm getObject cho hàng chục kiểu đối tượng khác nhau, khác hàng chục hàm getObject nằm hai bước dùng XML để định cấu hình (configure) miêu tả Với đà phát triển dự án, số lượng kiều object (object type) hoàn toàn lên tới hàng nghìn, có hàng nghìn hàm getObject đòi hỏi phải có bảo trì sửa đổi có sửa đổi thiết kế từ thực tế sản xuất Còn nhiều sai lầm phân tích thiết kế hệ thống việc thực dự án, khuôn khổ viết có hạn, nữa, sai lầm lại có sai lầm nghiêm trọng tính điển hình, phần nhiều hệ thiếu kiến thức, kinh nghiệm sai lầm có phân tích, không đề cập tới Những học rút từ Dự án _ Một quy trình tốt, thực đủ tất bước không bảo đảm cho thành công Dự án phần mềm Quy trình sử dụng Dự án công ty N Rational Unified Process, quy trình chuẩn công nghiệp sử dụng rộng rãi phát triển phần mềm, chi tiết thực bước sai, nên không đem lại kết Sử dụng công nghệ tốt, theo chuẩn công nghiệp không bảo đảm cho thành công Dự án phần mềm Công nghệ sử dụng Dự án công ty N J2EE Oracle database, công nghệ tốt cho Enterprise Software, có chuẩn công nghiệp chi tiết kỹ thuật (Technical Specification) rõ ràng, với đầy đủ công cụ (tool) tiện ích (utility) để phát triển Nhưng sử dụng phương pháp, nên kết phần mềm chắp vá, chất lượng, không sử dụng Những công cụ lập trình phần mềm tiện ích tốt không đảm bảo cho thành công dự án phần mềm Các công cụ sử dụng dự án ClearCase,Rational Rose, Eclipse, Aphelion, Apache, Tomcat … công cụ thử thách chứng tỏ tốt Công nghệ Phần mềm Nhưng sử dụng không đúng, nên không giúp ích nhiều cho trình làm việc, không tạo sản phẩm tốt Những học từ dự án phần mềm Con người khâu quan trọng Dự án Phần mềm Chính Ban Lãnh đạo Dự án Kiến trúc sư Phần mềm Dự án đủ lực để quản lý, thiết kế thi hành Dự án, nên Dự án dẫn đến tình trạng trình bày viết Khi bắt tay vào việc tiến hành Hệ thống Phần mềm, việc phải tìm đội ngũ nhân có trình độ thích hợp với quy mô độ phức tạp dự tính có Dự án, sau tiến hành thu thập thông tin, phân tích thiết kế thực Thực ra, phần chuẩn bị Nhân phần khó khăn Dự án phần mềm, nhiều công ty sản xuất dịch vụ sẵn chuyên gia nhân viên kỹ thuật có trình độ Phần mềm cao để vấn tuyển người cho Dự án Ngay công ty sản xuất dịch vụ có phận IT riêng, người phận thường trình độ cao, yêu cầu công việc thường xuyên hàng ngày không đòi hỏi nhân viên phải có trình độ chuyên môn cao Hơn nữa, khởi đầu việc tuyển người cho phận IT nội bộ, có nhiều khả công ty sản xuấtvà dịch vụ người có đủ trình độ để vấn xét tuyển nhân viên Giải pháp cho vấn đề nhân cho Dự án phần mềm lớn phức tạp là: Đầu tiên phải thuê công ty Tư vấn Giải pháp Công nghệ Thông tin để thu thập thong tin sơ làm phác thảo ước tính quy mô Độ Phức tạp Dự án Sau dựa vào công ty Cung cấp Nhân chuyên nghiệp để thuê nhân viên quản trị Dự án (Project Manager) Kiến trúc sư Phần mềm (Software Architect) có 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 trình, phác thảo thiết kế … Làm theo cách này, đảm bảo tính chuyên môn hóa cao, công ty chuyên Tư vấn Giải pháp Công nghệ Thông tin có chuyên môn cao việc thu thập thông tin thực tế phác họa giải pháp, công ty Cung cấp Nhân có chuyên môn cao có chuyên gia với trình độ chuyên ngành cần thiết việc tìm kiếm, vấn xét tuyển nhân viên Tuy nhiên, 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 Cung cấp Nhân hoạt động, nhiều số đủ kinh nghiệm, trình độ kiến thức cần có cho Dự án có quy mô lớn phức tạp Do đó, việc chọn công ty Tư vấn Giải pháp Cung cấp Nhân để thuê cần phải tiến hành cẩn thận Sau hoàn thành tốt khâu Chuẩn bị Nhân sự, khâu khác Dự án tiến hành cách thuận lợi, Quản trị Dự án Kiến trúc sư Phần mềm có kinh nghiệm, kiến thức biết phải điều hành dự án theo Quy trình nào, tiến hành việc thu thập thông tin, phân tích, hệ thống, đánh giá sao, tổ chức đội ngũ giao tiếp nhóm làm việc nào, tuyển lập trình viên nhân viên phân tích với tiêu chuẩn trình độ cho phù hợp, lựa chọn công cụ, tiện ích để quản lý, theo dõi công việc công cụ lập trình cách tối ưu Tất nhiên, công việc kể dễ dàng, với đội Những học từ dự án phần mềm ngũ Lãnh đạo tốt, có kinh nghiệm, kiến thức khả tiến hành tốt bước Dự án cao, Dự án có khả thành công thời hạn phạm vi ngân sách Hy vọng qua study case này, bạn đọc rút điểm yếu xảy khía cạnh khác Dự án Phần mềm Quy trình Quản lý Dự án (Project Management Process), Quy trình Phát triển Phần mềm (Software Development Process) Kiến trúc Phần mềm (Software Architecture) qua giai đoạn (phase) khác chu kỳ phát triển phần mềm (Software Development Lifecycle) Khởi đầu (Inception), Dự thảo Chi tiết (Elaboration), Thực xây dựng (Construction) Có điều, giai đoạn trình bày Dự án công ty N Chu kỳ phát triển Phần mềm đầy đủ (Full Lifecycle Software Development) Dự án chưa có, giai đoạn Chuyển giao (Transition) U.S.A 1-8-2005 JMS Chú thích _ [1] Trước làm việc vài năm vị trí Senior Software Engineer, Software Architect R&D Team leader Windchill R&D (Research and Development) PTC [2] Trong thời gian làm Windchill R&D, công việc nghiên cứu phát triển công nghệ thiết kế Windchill foundation, có tham gia hỗ trợ trực tiếp cho dự án triển khai Windchill Rolls Royce (Anh), Airbus (Pháp) 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 toàn trình học (summa cum laude) trường Duke, Master 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 Bộ phận Nghiên cứu Phát triển Công nghệ IBM, tham gia Ban Nghiên cứu Bộ Quốc phòng nhiều Ủy ban Nghiên cứu Liên bang Quốc gia khác Các giải thưởng, huy chương Phát minh Công nghệ ông trao Học Viện Hoàng gia Anh, Học viện Hoàng gia Hà lan, Viện nghiên Những học từ dự án phần mềm cứu Liên bang Thụy sĩ, Viện nghiên cứu, trường Đại học Ủy ban Quốc gia Mỹ liệt kê hết phải tốn nhiều trang giấy khổ A4 Ông có hai Phát minh Sáng chế Mỹ (U.S Pattern) lĩnh vực Computer Science Ông tham gia quản trị nhiều dự án nghiên cứu công nghệ phát triển phần mềm công nghiệp Danh mục tác phẩm khoa học bao gồm sách, viết, tài liệu nghiên cứu … liệt kê tốn nhiều trang A4 [4] Có trường hợp áp dụng Memento Design Pattern Swing GUI Dự án lý thú, sáng tạo Swing Developer nằm thiết kế dự án Lác đác Java code dự án có vài chỗ có ứng dụng tốt Design Pattern, toàn lập trình viên giàu kinh nghiệm dự án áp dụng, tài liệu thiết kế (Design Document) Mô hình Đối tượng (Object Model), từ Ban Lãnh đạo Dự án Kiến trúc sư phần mềm mà có [5] MVC: Model-View-Controller Chi tiết lý thuyết ví dụ ứng dụng MVC Design Pattern lập trình Java tìm thấy PC World Vietnam tháng năm 2005 […] [6] Trong ngôn ngữ lập trình Java, interface có chức quan trọng: Java không hỗ trợ (support) việc thừa kế từ nhiều lớp đối tượng (multiple inheritance), interface cung cấp công cụ để lớp đối tượng cài đặt (implement) nhiều interface, qua thừa kế hành vi (behavior) nhiều loại đối tượng khác Java interface tách biệt chức (functionality) cách cài đặt chức (implementation) Đây đặc điểm quan trọng, giúp cho thành phần (component) hệ thống OOP tương tác với nhau, không phụ thuộc chặt chẽ vào cách cài đặt nhau, thành phần dùng lại nhiều hệ thống, dễ bảo trì, mở rộng Java interface có tác dụng đánh dấu (marker interface), xác định với hệ thống lớp đối tượng (class) cài đặt (implement) interface, lớp đối tượng hệ thống thao tác sử dụng theo số phương pháp định Một ví dụ marker interface Serializable interface Java interface có tác dụng định nghĩa phương thức (method) nhằm mục đích bắt buộc lớp đối tượng (class) cài đặt (implement) interface này, phải có phương thức (method) có interface Chức dung để thiết kế Những học từ dự án phần mềm framework mà hành vi cụ thể mở rộng thay đổi cách thực tương lai, hành vi phải thực biết, cách thức thực chưa biết vào thời điểm viết chương trình, mà biết chạy chương trình (run-time) Trong design pattern, chức sử dụng nhiều Template Method Strategy pattern [7] Một ví dụ mở rộng chức thông qua Kế thừa (Inheritance) thông qua Bao gồm (Composition) Giả sử hệ thống liệu hàng điện tử ta có nhiều loại thiết bị cần quản lý, có Phone (Điện thoại), Camera (máy ảnh), CameraPhone (Điện thoại có máy ảnh) Digital Camera (Máy ảnh kỹ thuật số) Ta nhận thấy CameraPhone có chức Phone Camera, mở rộng từ Phone Camera DigitalCamera thuộc họ Camera, mở rộng từ Camera Mở rộng thông qua kế thừa: Trong Java thừa kế từ nhiều lớp (multiple Inheritance), nên ta phải định nghĩa Camera Phone Interface, định nghĩa CameraPhone implementation interface Camera interface Phone Như lớp CameraPhone, ta phải viết code cho chức Phone Camera Tương tự, ta định nghĩa DigitalCamera implementation Camera, Camera, ta phải viết code cho Camera * Lợi: Xây dựng hệ thống lớp đối tượng có chung số chức định (ví dụ DigitalCamera CameraPhone có chung chức chụp ảnh) * Hại: Trùng lặp code (trong DigitalCamera CameraPhone có code cho chức chụp ảnh, hoàn toàn giống nhau, chụp ảnh digital) Dễ gây tính thiếu tự nhiên thiết kế lỗi chạy chương trình (ví dụ API dành cho interface Phone gọi truyền cho tham số CameraPhone, sau dùng reflection để gọi method đối tượng truyền làm tham số, API gọi chức Camera, điều hoàn toàn sai không dự tính cho API này) Tạo nhiều lớp đối tượng cách không cần thiết (mỗi lần cần mở rộng tính lại phải dẫn suất (derive) lớp đối tượng mới) Mở rộng thông qua Bao gồm (Composition): Những học từ dự án phần mềm Ta định nghĩa Phone class có chức điện thoại, Camera class có chức máy ảnh Như CameraPhone định nghĩa lớp đối tượng có hai thành viên (member variable) Camera Phone Khi chức Phone CameraPhone gọi, CameraPhone gửi lệnh gọi tới biến thành viên (member) Phone, chức Camera CameraPhone gọi, CameraPhone gửi lệnh gọi tới thành viên Camera Đối với DigitalCamera, ta có chọn lựa rộng rãi hơn, kế thừa (inherit) định nghĩa chồng (override) chức Camera, chức cài đặt giống nhau, định nghĩa DigitalCamera có biến thành viên Camera, gửi lệnh gọi chức Camera tới thành viên Lợi: Giảm trùng lặp code Tạo chức cách dễ dàng cách bổ sung biến thành viên Hại: Trong trường hợp đối tượng cần có chức khác chức có sẵn biến thành viên (ví dụ chức chụp ảnh DigitalCamera khác chưa chụp ảnh Camera, chức nạp pin, lau ống kính giống), có dư thừa code (vì chức chụp ảnh phải viết mới, trong biến thành viên Camera có chức chụp ảnh) Tất nhiên, luật tuyệt đối (hard and fast rule) cho việc trường hợp phải mở rộng chức Inheritance, trường hợp phải sử dụng Composition hay Design Pattern Có hiệu tiếng giới lập trình “Prefer composition over Inheritance” Tuy vậy, điều phụ thuộc vào yêu cầu thực tế, trình độ, kỹ kinh nghiệm kiến trúc sư phần mềm (Software Architect), có tính nghệ thuật cao Nhưng Dự án phần mềm mà có mở rộng chức đối tượng Inheritance (trong có trường hợp dùng phương pháp khác tốt hơn) tuyệt đối không được, thể trình độ thiếu hiểu biết kiến trúc sư phần mềm ... nhiều lần Những học từ dự án phần mềm Hiện tượng xảy Ban Lãnh đạo Dự án không hiểu ý nghĩa cách vận dụng Iterative Development, đồng thời Kiến trúc sư Phần mềm (Software Architect) Dự án tầm nhìn... không sử dụng Những học từ dự án phần mềm Do thiếu hiểu biết kiến trúc chức Windchill, nên cần có chức sơ đẳng bản, Nhóm Phần mềm Dự án phải làm từ đầu, phát minh lại nhiều bánh xe, thiếu hiểu... tốt Công nghệ Phần mềm Nhưng sử dụng không đúng, nên không giúp ích nhiều cho trình làm việc, không tạo sản phẩm tốt Những học từ dự án phần mềm Con người khâu quan trọng Dự án Phần mềm Chính Ban