PHẦN MỀM TIẾN TRÌNH VÀ QUẢN LÝ

Chương 1: PHẦN MỀM TIẾN TRÌNH VÀ QUẢN LÝ 1.1 Phần mềm công nghệ phần mềm 1.1.1 Lịch sử mục tiêu công nghệ phần mềm Ngay từ xuất hệ máy tính ngơn ngữ lập trình phần mềm bắt đầu xuất Tuy nhiên, loại phần cứng giới thiệu – phần cứng dựa vào dòng điện tích hợp (integrated circuits) hay cịn gọi chip điện tử - việc phát triển phần mềm rơi vào khủng hoảng - Các đơn đặt hàng yêu cầu phần mềm có kích thước lớn độ phức tạp cao ngày nhiều, việc phát triển phần mềm theo cách từ trước ngày không phù hợp - Nhiều dự án lớn bị trễ thời gian dài - Chi phí phần mềm lớn nhiều so với dự đốn - Phần mềm ngày khơng đáng tin cậy, khó bảo trì thực thi cách nghèo nàn (performed poorly) Do đó, để kiểm sốt (control) độ phức tạp này, kỹ thuật phương pháp cần sử dụng công nghệ phần mềm đời 1.1.1.1 Định nghĩa “Cơng nghệ phần mềm” Có nhiều định nghĩa CNPM: - Theo Fritz Bauer [1969]: CNPM thiết lập sử dụng nguyên tắc công nghệ hợp lý để đạt phần mềm có tính kinh tế mà đáng tin cậy làm việc hiệu máy thực - Theo IEEE [1993]: CNPM (1) việc áp dụng phương pháp tiếp cận có tính hệ thống, số lượng xác định việc phát triển, hoạt động bảo trì phần mềm; việc áp dụng cơng nghệ vào phần mềm (2) nghiên cứu phương pháp tiếp cận (1) - Theo Roger S Pressman: CNPM mơn tích hợp quy trình, phương pháp, cơng cụ để phát triển phần mềm máy tính - Theo Ian Sommerville: CNPM lĩnh vực mà liên quan đến tất khía cạnh sản xuất phần mềm từ giai đoạn đầu đặc tả hệ thống đến bảo trì hệ thống sau đưa vào sử dụng 1.1.1.2 Lịch sử đời Năm 1968: Tây Đức, hội nghị khoa học NATO đưa từ “Software Engineering” (Công nghệ phần mềm) Bắt đầu bàn luận khủng hoảng phần mềm (Software Crisis) xu hướng hình thành CNPM chuyên môn riêng Nửa cuối 1968: IBM đưa sách phân biệt giá phần cứng phần mềm Từ đó, ý thức phần mềm ngày cao Bắt đầu nghiên cứu phương pháp luận lập trình Nửa đầu năm 1970: Nhằm nâng cao chất lượng phần mềm, nghiên cứu lập trình, kiểm thử, mà cịn có nghiên cứu đảm bảo tính tin cậy trình sản xuất phần mềm Năm 1975: Hội nghị quốc tế CNPM tổ chức: International Conference on SE (ICSE) Nửa sau năm 1970: Quan tâm đến pha trình phát triển phần mềm, tập trung pha đầu ICSE tổ chức lần 2, vào 1976, 1978 1979 - Nhật Bản có “Kế hoạch phát triển kỹ thuật sản xuất phần mềm” từ năm 1981 - Cuộc “Cách tân sản xuất phần mềm” bắt đầu phạm vị nước công nghiệp Nửa đầu năm 1980: Trình độ học vấn ứng dụng CNPM nâng cao, công nghệ chuyển vào thực tế Xuất sản phẩm phần mềm công cụ khác làm tăng suất sản xuất phần mềm đáng kể - ICSE tổ chức lần vào năm 1981 1982 với 1000 người tham dự năm - Nhật Bản sang “Kế hoạch phát triển kỹ thuật bảo trì phần mềm” (1981 – 1985) Nửa cuối năm 1980 đến nay: Từ học vấn sang nghiệp vụ Chất lượng phần mềm tập trung chủ yếu tính suất, độ tin cậy tính bảo trì Nghiên cứu tự động hóa sản xuất phần mềm - Nhật Bản có “Kế hoạch hệ thống cơng nghiệp hóa sản xuất phần mềm” (SIGMA: Software Industrialized Generator & Maintenance Aids, 1985-1990) - Nhiều trung tâm, viện nghiên cứu CNPM đời Các trường đưa vào giảng dạy SE 1.1.1.3 Mục tiêu Là cung cấp cấu trúc cho việc xây dựng phần mềm có chất lượng cao: tính đắn độ tin cậy cao, dễ sử dụng, thân thiện với người dùng, dễ hiểu,… 1.1.2 Tiêu chuẩn sản phẩm phần mềm Để đánh giá sản phẩm phần mềm, người ta thường đánh giá theo khía cạnh: chất lượng bên (internal qualities) chất lượng bên (external qualities) 1.1.2.1 Chất lượng bên Người dùng đánh giá chất lượng phần mềm thông qua yếu tố chất lượng bên ngoài, như: tính dễ sử dụng, tính tin cậy, tính chức năng,… Những yếu tố bao gồm thuộc tính chức (functional attributes) thuộc tính phi chức (non-functional attributes) Những thuộc tính chức miêu tả chức mà sản phẩm phần mềm phải thực (describe WHAT the product MUST do), thuộc tính phi chức lại miêu tả cách thức chương trình thực thi (describe HOW the product SHOULD be implemented) Các yếu tố chất lương bên xem xét thông qua số câu hỏi kèm: - Tính dễ sử dụng (usability): giao diện có thân thiện khơng? Các thao tác thực có gần gũi khơng?,… - Tính tin cậy (reliability): chức chương trình thực chứ? Các cơng thức tính tốn cho kết mong muốn? liệu lưu vào DB mong muốn? phần mềm chạy ổn định? - Tính chức (functionality): chức thực đúng? Các cơng thức tính tốn cho kết mong muốn? Các liệu lưu vào DB mong muốn? Tính chức trả lời số câu hỏi giống tính tin cậy xét phạm vi chức Giả sử phần mềm có chức năng: tính đắn quan tân đến chức riêng rẽ, tính tin cậy quan tâm đến lien kết, rang buộc chức với - Tính bền vững (stability): phần mềm hoạt động điều kiện khác nhau? Trong môi trường khác nhau? - Tính tương thích (compatibility): phần mềm dễ dàng tích hợp với sản phẩm phần mềm khác? - Tinh thực thi (performance): phần mềm chạy với tốc độ nhanh hay chậm? chạy có sử dụng nhiều tài ngun máy tính khơng: nhớ, xử lý,…? Do yếu tố chất lượng bên người dùng đánh giá nên yếu tố quan trọng để định đến thành công hay thất bại phần mềm 1.1.2.2 Chất lượng bên Những yếu tố chất lượng bên yếu tố “trong suốt” với người dùng, người phát triển (developer) thấy Những yếu tố tài liệu tham gia vào trình phát triển phần mềm, như: tài liệu phân tích yêu cầu, tài liệu thiết kế,…và đoạn code.Tuy yếu tố chất lượng bên mục tiêu cuối yếu tố bên lại giúp đỡ người phát triển đạt cải tiến chất lượng bên ngồi 1.1.3 Cái nhìn chung cơng nghệ phần mềm 1.1.3.1 Nhân tố người Nhân tố người đóng vai trị quan trọng CNPM, mà viện CNPM phát triển “mơ hình tính trưởng thành khả quản lý người” (people management capability maturity model: PM-CMM) Mơ hình phát triển để làm tăng tính sẵn sàng tổ chức phần mềm việc đảm trách ứng dụng phức tạp ngày gia tăng cách thu hút, phát triển, thúc đẩy, triển khai, giữ lại tài cần thiết để cải tiến khả phát triển phần mềm A Những người tham gia dự án phần mềm Có thể chia thành loại sau: A1 Senior Managers: định nghĩa chiến lược kinh doanh có ảnh hưởng đáng kể đến dự án A2 Project (Technical) Managers: lập kế hoạch, thúc đẩy tinh thần làm việc, tổ chức kiểm sốt thành viên làm cơng việc phần mềm A3 Practitioners: vận dụng kỹ kỹ thuật để làm sản phẩm hay ứng dụng A4 Customers: đưa yêu cầu phần mềm stakeholders khác A5 End-users: sử dụng phần mềm phần mềm đưa sử dụng Để đạt hiệu quả, đội dự án phải tổ chức sau cho sử dụng tối đa khả kỹ người Và cơng việc team leader B Project manager (PM), Project leader (PL) Team leader (TL) Trong sách mình, Jerry Weinberg đề nghị mơ hình MOI cho phận lãnh đạo Motivation (tính thúc đẩy, động lực): khả thúc đẩy, động viên thành viên kỹ thuật để sử dụng khả tốt họ cho việc sản xuất ứng dụng Organization (tính tổ chức): khả sử dụng tiến trình tồn để tạo sản phẩm cuối Ideas or innovation (sáng kiến cải tiến mới): khả thúc đẩy, động viên tính sáng tạo người, họ làm giới hạn thiết lập Đối với problem gặp phải, leader manager phải hiểu rõ vấn đề để đưa hướng giải xác đáng thích hợp Chính vậy, người leader hay manager có hiệu nhấn mạnh điểm sau: Problem solving (giải vấn đề): PM hiệu phân tích vấn đề kỹ thuật tổ chức, đưa giải pháp, áp dụng học từ dự án trước tình trạng mới, đủ linh hoạt để thay đổi hướng giải cố gắng ban đầu để giải vấn đề không thu hiệu Managerial identity (đặc tính quản lý): PM giỏi phải chịu trách nhiệm dự án, phải biết nắm lấy quyền kiểm soát cần thiết cho phép thành viên phát huy khả kỹ thuật Achievement (thành tích): để tối ưu hóa suất đội dự án, người quản lý phải khen thưởng hành động thiết thực đội hoàn thành dự án, người gây rủi ro cho dự án không bị trừng phạt nặng Influence and team building (ảnh hưởng xây dựng đội): PM hiệu phải hiểu thành viên đội muốn có phản ứng trở lại với nhu cầu C Đội phần mềm (software team) Cấu trúc đội dự án tùy thuộc vào cách quản lý tổ chức, số lượng người tham gia vào đội, mức độ kỹ người độ khó vấn đề Mantei đề xuất hướng tổ chức đội thành loại sau: Democratic decentralized (DD) (phân quyền dân chủ): đội khơng có leader lâu dài Các leader thay theo task Những định vấn đề phương pháp thực thi đưa dựa vào trí nhóm Việc giao tiếp, truyền thơng thành viên nhóm ngang hàng Controlled decentralized (CD) (phân quyền có kiếm sốt): đội loại có leader chịu trách nhiệm task cụ thể leader thứ hai chịu trách nhiêm task Việc giải vấn đề hoạt động chung nhóm, nhiên việc thực giải pháp lại công việc nhóm Việc giao tiếp, truyền thơng nhóm thành viên ngang hàng Việc truyền thông phân cấp xuất theo phân cấp quyền kiểm soát Controlled centralized (CC) (tập trung kiểm soát): việc giải vấn đề mức độ cao điều phối nội team quản lý TL Việc giao tiếp, truyền thông leader thành viên nhóm theo chiều dọc (có phân cấp) Tuy nhiên, để lên cấu trúc đội nhân tố sau nên xem xét: - Độ khó vấn đề cần giải - Kích thước chương trình theo dòng code đoạn chức - Thời gian mà đội làm việc với - Mức độ/ trình độ để mơ hình hóa vấn đề - Chất lượng đòi hỏi độ tin cậy hệ thống xây dựng - Tính khắt khe ngày giao - Mức độ truyền thơng địi hỏi nhóm Bởi cấu trúc tập trung hoàn thành task nhanh hơn, nên thích hợp việc kiểm sốt vấn đề đơn giản Những đội phân quyền tạo nhiều giải pháp giải pháp tốt cá nhân nghĩ Hơn nữa, đội có khả thành cơng việc giải vấn đề khó Vì vậy, đội CD tập trung cho việc giải vấn đề, cấu trúc đội CD hay CC áp dụng thành công vấn đề đơn giản Cấu trúc DD tốt cho vấn đề khó Cấu trúc CC hay CD thường giao cho dự án lớn nhóm hoàn thành task dễ dàng Thời gian sống đội ảnh hưởng đến tinh thành làm việc đội Cấu trúc đội DD cho tinh thần làm việc độ hài lịng cơng việc cao tốt cho đội sống thời gian dài Để đội đạt thực thi cao thì: - Các thành viên đội phải tin tưởng lẫn - Sự phân phối kỹ phải thích hợp với vấn đề - Những khuyết điểm đội phải loại trừ để trì gắn kết đội D Vấn đề điều phối truyền thông (coordination and communication issue) Những phần mềm ngày có đặc tính sau: - Scale (tính tỷ lệ): tỷ lệ cố gắng phát triển phần mềm lớn, dẫn đến độ phức tạp, mơ hồ độ khó đáng kể việc điều hướng thành viên đội - Uncertainty (tính bất định): bất định phần mềm phổ biến, dẫn đến chuỗi thay đổi tiếp diễn mà ảnh hưởng đến đội dự án - Interoperability (khả tương tác): trở thành đặc trưng nhiều hệ thống Phần mềm phải tương tác với phần mềm cũ phù hợp với ràng buộc nêu trước hệ thống sản phẩm Để giải đặc tính cách hiệu quả, đội CNPM phải xây dựng phương pháp hiêu cho việc điều hướng thành viên Để hồn thành điều đó, cấu truyền thông/ giao tiếp thân mật lịch thành viên đội phải thiết lập Kraul Streeter xem xét tập hợp kỹ thuật điều hướng dự án phân loại thành loại sau: - Formal, impersonal approaches (phương thức lịch sự, khách quan): gồm tài liệu kỹ thuật phần mềm giao nộp (source code), ghi kỹ thuật, mốc dự án, lịch biểu công cụ kiểm soát dự án, yêu cầu thay đổi tài liệu liên quan, báo cáo lưu vết lỗi, liệu dự án - Formal, interpersonal procedures (những thủ tục lịch sự, cá nhân): tập trung vào hoạt động đảm bảo chất lượng, áp dụng cho sản phẩm công việc CNPM, bao gồm review meetings, design and code inspections - Informal, interpersonal procedures (những thủ tục thân mật, cá nhân): gồm họp nhóm để phổ biến thơng tin, giải vấn đề “sự xếp yêu cầu đội phát triển” - Electronic communication (truyền thông điện tử): gồm email, bảng tập san điện tử, hội nghị qua video - Interpersonal networking (mạng cá nhân): gồm thảo luận thân mật thành viên ngồi dự án (những thành viên có kinh nghiệm hiểu biết hỗ trợ thành viên đội dự án) 1.1.3.2 Các loại phần mềm Ngày nay, phần mềm áp dụng ngày rộng rãi, hoàn cảnh Nội dung thông tin rõ rang nhân tố quan trọng việc xác định chất phần mềm ứng dụng Nội dung thông tin đề cập đến ý nghĩa hình thức thơng tin vào Các phần mềm ứng dụng doanh nghiệp sử dụng liệu đầu vào có cấu trúc cao (database) để tạo báo cáo có định dạng Trong đó, rõ ràng thơng tin đề cập đến dự đốn trình tự thời gian thơng tin Một chương trình phân tích kỹ nghệ chấp nhận liệu có trình tự xác định trước thực thuật tốn phân tích mà không gián đoạn đưa kết báo cáo hay định dạng đồ họa Dựa vào mục đích sử dụng chất phần mềm mà phân mềm chia thành loại sau: - System software (phần mềm hệ thống): tập hợp chương trình viết để phục vụ chương trình khác, như: drivers, compilers, editors,… - Real-time software (phần mềm thời gian thực): phần mềm giám sát, phân tích kiểm sốt kiện xảy giới thực xảy Các yếu tố phần mềm thời gian thực là: (1) thu thập thơng tin từ bên ngồi (2) phân tích chuyển đổi thông tin vào ứng dụng (3) kiểm soát liệu đầu (4) giám sát kiện bên ngồi để trì phản ánh cách xác - Business software (phần mềm nghiệp vụ): phần mềm xử lý thông tin doanh nghiệp Các hệ thống rời rạc (tính lương, khoản thu chi,…) phát triển thành phần mềm MIS(Management Information System) truy cập số lương lớn thông tin doanh nghiệp - Engineering and scientific software (phần mềm khoa học ứng dụng): phần mềm sử dụng thuật tốn để phân tích chuyển đổi số - Embedded software (phần mềm nhúng): phần mềm nằm ROM (read-only memory) dùng để kiểm soát sản phẩm hệ thống - Personal computer software (phần mềm máy tính cá nhân) - Web-based software (phần mềm ứng dụng web) - Artificial Intelligence software (phần mềm trí tuệ nhân tạo): phần mềm sử dụng thuật tốn khơng số (non-numerical algorithms) để giải vấn đề phức tạp, không tuân theo quy luật nào, như: hệ thống nhận dạng mơ hình (âm thanh, hình ảnh), mạng lưới thần kinh nhân tạo (artificical neural networks) 1.1.3.3 Tiến trình phần mềm (software process) A Tổng quan tiến trình phần mềm Tiến trình phần mềm tập hợp hoạt động để sản xuất phần mềm Những hoạt động liên quan đến việc phát triển phần mềm từ thứ lộn xộn vào ngơn ngữ lập trình chuẩn java, C Tuy nhiên, phần mềm đa số phát triển cách mở rộng hay nâng cấp phần mềm tồn Những tiến trình phần mềm phức tạp giống tất tiến trình thơng minh có tính sáng tạo khác, tiến trình phần mềm dựa vào người đưa định chuẩn đoán Bởi cần thiết việc chuẩn đoán sáng tạo nên họ sức cố gắng tự động hóa tiến trình phần mềm đáp ứng thành cơng có giới hạn Những công cụ Công Nghệ Phần Mềm Hỗ Trợ Máy Tính (Computer- aided software engineering CASE) hỗ trợ số họat động tiến trình Tuy nhiên, vài năm nữa, khơng có khả cho tự động hóa mở rộng hơn, phần mềm đảm nhận việc thiết kế kỹ sư liên quan đến tiến trình phần mềm Một lý do, hiệu công cụ CASE bị giới hạn có q nhiều tiến trình phần mềm Khơng có tiến trình lý tưởng nhiều tổ chức lại phát triển tiến trình riêng họ để phát triển phần mềm Những tiến trình đưa để khai thác khả người tổ chức đặc tính cụ thể hệ thống mà họ phát triển Đối với số hệ thống, hệ thống quan trọng, tiến trình phát triển cấu trúc đòi hỏi Đối với hệ thống thương mại, với yêu cầu bị thay đổi cách nhanh chóng, tiến trình nhanh nhẹn linh hoạt hiệu Mặc dù có nhiều tiến trình phần mềm, số hoạt động tảng phổ biến chung cho tất tiến trình Đặc tả phần mềm (Software specification): chức phần mềm ràng buộc họat động phải định nghĩa Thiết kế thực thi phần mềm (Software design and implementation): phần mềm đáp ứng đặc tả phải tạo Chứng nhận phần mềm: phần mềm phải chứng nhận để đảm bảo làm mà khách hàng muốn Tiến triển phần mềm: phần mềm phải tiến triển để đáp ứng nhu cầu thay đổi khách hàng Mặc dù khơng có tiến trình phần mềm lý tưởng, lại có phạm vi cho việc cải tiến tiến trình phần mềm tổ chức Những tiến trình bao gồm kỹ thuật chưa cập nhật Thực vậy, nhiều tổ chức khơng có thuận lợi phương pháp công nghệ phần mềm phát triển phần mềm họ Những tiến trình phần mềm cải tiến chuẩn hóa tiến trình nơi mà đa dạng tiến trình phần mềm tổ chức giảm bớt Điều dẫn đến truyển thông cải tiến giảm bớt thời gian huấn luyện làm Customer communication (giao tiếp với khách hàng): thiết lập giao tiếp có hiệu người phát triển khách hàng Planning (lập kế hoạch): xác định tài nguyên, thời hạn thơng tin khác Risk analysis (phân tích rủi ro): xem xét rủi ro kỹ thuật rủi ro quản lý Engineering (kỹ thuật): xây dựng hay số biểu diễn ứng dụng Construction & release (xây dựng phát hành): xây dựng, kiểm thử, cài đặt cung cấp hỗ trợ người dùng (tư liệu, huấn luyện,…) Customer evaluation (đánh giá khách hàng): nhận phản hồi người dùng biểu diễn phần mềm giai đoạn kỹ thuật cài đặt Khi tiến trình bắt đầu, đội CNPM di chuyển vào xoắn ốc theo chiều kim đồng hồ, bắt đầu tâm Mơ hình xoắn ốc áp dụng xuyên suốt chu kỳ sống phần mềm Mỗi khối lập phương đặt trục tọa độ đại diện cho điểm bắt đầu loại dự án khác “Concept development projects” bắt đầu lõi xoắn ốc tiếp tục phát triển khái niệm hoàn thành Nếu khái niệm phát triển thành sản phẩm thật, tiến trình tiến đến hình lập phương tiếp theo, “new development projects” khởi tạo Sản phẩm tiến triển suốt số lượng lớn lần lặp quanh xoắn ốc phần mềm khơng cịn sử dụng Bất có thay đổi tiến trình bắt đầu vị trí hình lập phương thích hợp Mơ hình xoắn ốc tốt cho hệ phần mềm quy mơ lớn Nó sử dụng mơ hình mẫu chế loại trừ lỗi, cho phép nhà phát triển áp dụng mơ hình mẫu chu trình phát triển Tuy nhiên, lại khó thuyết phục khách hàng kiểm sốt tiến hóa phần mềm, địi hỏi phải có kỹ cao việc đánh giá lỗi Cuối cùng, mơ hình xoắn ốc chưa sử dụng phổ biến mơ hình thác nước mơ hình mẫu C6 Mơ hình RAD (Rapid Application Development - RAD model) Mơ hình RAD mơ hình tiến trình phát triển phần mềm tăng dần mà nhấn mạnh vào chu trình phát triển cực ngắn cách sử dụng xây dựng dựa thành phần Nếu yêu cầu hiểu tốt phạm vi dự án xác định, tiến trình RAD cho phép đội phát triển tạo hệ thống chức đầy đủ khoảng thời gian ngắn (60 – 90 ngày) ... 1.1.3.3 Tiến trình phần mềm (software process) A Tổng quan tiến trình phần mềm Tiến trình phần mềm tập hợp hoạt động để sản xuất phần mềm Những hoạt động liên quan đến việc phát triển phần mềm từ... đến tiến trình phần mềm Một lý do, hiệu cơng cụ CASE bị giới hạn có q nhiều tiến trình phần mềm Khơng có tiến trình lý tưởng nhiều tổ chức lại phát triển tiến trình riêng họ để phát triển phần mềm. .. công nghệ phần mềm phát triển phần mềm họ Những tiến trình phần mềm cải tiến chuẩn hóa tiến trình nơi mà đa dạng tiến trình phần mềm tổ chức giảm bớt Điều dẫn đến truyển thông cải tiến giảm bớt