Bài giảng Công nghệ phần mềm - Bài 1: Ngôn ngữ lập trình - Lê Nguyễn Tuấn Thành
Định nghĩa
Phần mềm là các chương trình máy tính và những tài liệu
liên quan (đặc tả yêu cầu, mô hình thiết kế, tài liệu hướng
dẫn sử dụng, )
Sản phẩm phần mềm được chia thành 2 loại:
1. Đại trà (Generic Product): được phát triển để bán cho một loạt
các đối tượng khách hàng khác nhau. Ví dụ: các phần mềm PC như
Excel hoặc Word
2. Chuyên biệt (Bespoke/Customised Product): được phát triển cho
một khách hàng duy nhất theo yêu cầu của họ. Ví dụ: các phần mềm
cho ngành thuế, ngân hàng, điện lực
Một phần mềm mới có thể được tạo ra bằng cách:
Phát triển những chương trình mới,
Cấu hình những hệ thống phần mềm chung,
Sử dụng lại phần mềm có sẵnChi phí phần mềm
(Software Costs)
Chi phí cho phần mềm thường chi phối chi phí
cho hệ thống máy tính,
Chi phí của phần mềm trên PC thường lớn hơn chi
phí phần cứng,
Chi phí cho phần mềm tập trung chủ yếu vào khâu
bảo trì (maintain) hơn là khâu phát triển (develop).
Với những hệ thống có vòng đời dài, chi phí bảo trì có thể
gấp nhiều lần chi phí phát triển
Tóm tắt nội dung tài liệu: Bài giảng Công nghệ phần mềm - Bài 1: Ngôn ngữ lập trình - Lê Nguyễn Tuấn Thành
Công nghệ Phần mềm Phần mềm và Công nghệ phần mềm Bộ Môn Công Nghệ Phần Mềm – Khoa CNTT Trường Đại Học Thủy Lợi Giảng viên: Lê Nguyễn Tuấn Thành Email: thanhlnt@tlu.edu.vn Nội dung 2 1. Phần mềm 2. Công nghệ phần mềm 3. Quản lý dự án phần mềm 4. Quy trình phần mềm Bài giảng có sử dụng hình vẽ trong cuốn sách “Software Engineering, Ian Sommerville, 8th Edition, 2007” Câu hỏi? 3 1. Phần mềm là gì? 2. Những thuộc tính của một phần mềm tốt là gì? 3. Công nghệ Phần mềm là gì? 4. Những thách thức chính mà Công nghệ Phần mềm phải đối mặt là gì? 5. Sự khác nhau giữa Công nghệ Phần mềm và Khoa học Máy tính là gì? 6. Sự khác nhau giữa Công nghệ Phần mềm và Kỹ thuật Hệ thống (System Engineering) là gì? 7. Tiến trình phần mềm là gì? 8. Mô hình tiến trình phần mềm là gì? 9. Các chi phí của Công nghệ Phần mềm là gì? 10. Các phương thức Công nghệ Phần mềm là gì? 11. CASE (Computer-Aided Software Engineering) là gì? 1. Phần mềm là gì? What is the Software? 4 5 Tầm quan trọng 6 Nền kinh tế của TẤT CẢ các quốc gia phát triển phụ thuộc vào phần mềm, Ngày càng có nhiều hệ thống được kiểm soát bởi phần mềm, Chi tiêu cho phần mềm thể hiện một phần đáng kể của GNP1 ở tất cả các nước phát triển. [1] GNP (Gross National Product): Tổng sản lượng quốc gia Định nghĩa 7 Phần mềm là các chương trình máy tính và những tài liệu liên quan (đặc tả yêu cầu, mô hình thiết kế, tài liệu hướng dẫn sử dụng,) Sản phẩm phần mềm được chia thành 2 loại: 1. Đại trà (Generic Product): được phát triển để bán cho một loạt các đối tượng khách hàng khác nhau. Ví dụ: các phần mềm PC như Excel hoặc Word 2. Chuyên biệt (Bespoke/Customised Product): được phát triển cho một khách hàng duy nhất theo yêu cầu của họ. Ví dụ: các phần mềm cho ngành thuế, ngân hàng, điện lực Một phần mềm mới có thể được tạo ra bằng cách: Phát triển những chương trình mới, Cấu hình những hệ thống phần mềm chung, Sử dụng lại phần mềm có sẵn Chi phí phần mềm (Software Costs) 8 Chi phí cho phần mềm thường chi phối chi phí cho hệ thống máy tính, Chi phí của phần mềm trên PC thường lớn hơn chi phí phần cứng, Chi phí cho phần mềm tập trung chủ yếu vào khâu bảo trì (maintain) hơn là khâu phát triển (develop). Với những hệ thống có vòng đời dài, chi phí bảo trì có thể gấp nhiều lần chi phí phát triển Thuộc tính của Phần mềm TỐT 9 Khả năng bảo trì Phần mềm phải phát triển để đáp ứng nhu cầu thay đổi Đáng tin cậy Phần mềm phải thực sự đáng tin cậy Hiệu quả Phần mềm không nên tạo ra việc sử dụng lãng phí tài nguyên hệ thống Chấp nhận được Phần mềm phải được chấp nhận bởi người dùng mà nó được thiết kế. Điều này có nghĩa là nó có thể được hiểu, sử dụng và tương thích với những hệ thống khác. 2. Công nghệ Phần mềm là gì? What is the Software Engineering? 10 Công nghệ Xây dựng 11 Những bước nào cần phải làm? Quyết định cần xây những gì Quyết định công trình sẽ trông như thế nào Cần xây bao nhiêu tầng, mỗi tầng bao nhiêu phòng, mỗi phòng rộng bao nhiêu, Quyết định vật liệu xây dựng Lên kế hoạch dự án, lập lịch, làm việc nhóm Mô phỏng và kiểm tra Tiến hành xây dựng Hoạt động và bảo trì Thành phần trong phát triển phần mềm 12 Không chỉ là kỹ năng công nghệ 13 Các trường đại học có xu hướng tập trung vào công nghệ, bỏ qua yếu tố con người và quá trình thực hiện. Việc thực hiện theo quy trình có thể làm giảm tỷ lệ lỗi lên tới 75% Trong thực tế, lập trình thường chiếm ít thời gian làm nhất trong toàn bộ quá trình thực hiện dự án! Khía cạnh của CNPM 14 Những quy trình cần thiết để chuyển một khái niệm thành một sản phẩm (deliverable) có thể tiến hóa theo thời gian Làm việc với tài nguyên và thời gian bị giới hạn Phải thỏa mãn một khách hàng Quản lý rủi ro Làm việc nhóm và giao tiếp Định nghĩa 15 Công nghệ phần mềm là một quy trình kỹ thuật (engineering discipline) liên quan đến tất cả khía cạnh của sản xuất phần mềm CNPM liên quan tới các lý thuyết, phương pháp và công cụ cho việc phát triển phần mềm chuyên nghiệp CNPM liên quan đến việc phát triển phần mềm hiệu quả về chi phí. Liên quan đến nhiều lĩnh vực 16 computer science (algorithms,data structures, languages,tools) business/management (project mgmt,scheduling) economics/marketing (selling,niche markets,monopolies) communication (managing relations with stakeholders: customers, management,developers,testers, sales) law (patents, licenses, copyrights,reverse engineering) sociology (modern trends in societies, localization,ethics) political science (negotiations; topics at the intersection of law, economics,and global societal trends; public safety) psychology (personalities,styles, usability,what is fun) art (GUI design,what is appealing to users) necessarily "softer"; fewer clearly right/wrong answers Các vai trò 17 Khách hàng (customer / client) Muốn xây dựng phần mềm Thường không biết rõ họ muốn những gì Quản lý (managers) Tạo kế hoạch, phối hợp thành viên trong nhóm Khó dự đoán tất cả những vấn đề có thể phát sinh Người phát triển (developers) Thiết kế và viết mã nguồn Khó có thể viết mã nguồn phức tạp cho những hệ thống lớn Người kiểm thử (testers) Thực hiện đảm bảo chất lượng (QA – Quality Assurance) Không thể kiểm thử tất cả các trường hợp Người dùng (Users) Mua và sử dụng sản phẩm phần mềm Hay thay đổi và có thể hiểu sai sản phẩm Làm ra Phần mềm là việc khó 18 Historically, ~ 85% of software projects "fail”.Why? management sets unrealistic expectations; devs don't correct them overestimating the positive impact of shiny new tools and hardware hired developers based on availability despite warning signs personality conflicts between developers changes in rate structure requirements in middle of work one delay causes another (dev delay leads to test delay, etc.) hacks and shortcuts developers end up working "death marches" (6-day, 10-hour weeks) overestimating how nearly done you are ("I'm 90% there!") software written doesn't match the spec developer time taken away by other tasks tons of bugs come out in testing developers don't listen to testers; ignore severity of bugs reported management breaking promises (bonuses, time off, etc.) Công nghệ Phần mềm vs. Khoa học Máy tính 19 Công nghệ Phần mềm Khoa học máy tính Liên quan đến việc thực hành để phát triển và phân phối phần mềm hữu ích Liên quan tới học thuyết và những nguyên lý cơ bản Các học thuyết khoa học máy tính vẫn chưa đủ để đóng vai trò là cơ sở hoàn chỉnh cho công nghệ phần mềm (không giống như các ngành Vật lý hay Kỹ thuật điện) Công nghệ Phần mềm vs. Kỹ thuật Hệ thống 20 Công nghệ Phần mềm Kỹ thuật Hệ thống Là một phần của Kỹ thuật Hệ thống liên quan tới phát triển hạ tầng phần mềm, điều khiển, ứng dụng và cơ sở dữ liệu trong hệ thống Liên quan đến tất cả khía cạnh của phát triển hệ thống dựa trên máy tính bao gồm phần cứng, phần mềm và quy trình kỹ thuật Kỹ sư hệ thống liên quan đến đặc tả hệ thống (system specification), thiết kế kiến trúc (architectural design), tích hợp (integration) và triển khai (deployment) Hoạt động trong CNPM 21 Vòng đời phát triển phần mềm (Software Development Lifecycle - SDLC) Chi phí của Công nghệ Phần mềm 22 Gần 60% chi phí dành cho việc phát triển (development), khoảng 40% cho việc kiểm thử (test). Chi phí tiến hóa (evolution costs) thường vượt quá chi phí phát triển (development costs) Phân phối chi phí phụ thuộc vào mô hình phát triển được sử dụng Phân phối Chi phí theo hoạt động (Activity cost distribution) 23 Các phương pháp CNPM (Software Engineering Methods) 24 Những cách tiếp cận có cấu trúc để phát triển PM: Mô hình hệ thống (system models) Hệ thống ký hiệu (notations) Quy tắc (rules) Tư vấn thiết kế (design advice) Hướng dẫn quá trình (process guidance) Miêu tả mô hình Những miêu tả của mô hình đồ họa nên được tạo ra Quy tắc Những rằng buộc áp dụng cho mô hình hệ thống Khuyến cáo Những tư vấn cho thực hành thiết kế tốt Hướng dẫn quá trình Những hành động phải tuân theo Thách thức chính đối với CNPM 25 Tính không đồng nhất Phát triển những kỹ thuật để xây dựng phần mềm đáp ứng những nền tảng và môi trường thực thi không đồng nhất Sự phân phối Phát triển những kỹ thuật để dẫn đến phân phối phần mềm nhanh hơn Độ tin cậy Phát triển những kỹ thuật để chứng minh phần mềm có thể được sự tin tưởng bởi người dùng Trách nhiệm chuyên môn và đạo đức 26 CNPM liên quan đến những trách nhiệm hơn là đơn giản chỉ áp dụng những kỹ năng kỹ thuật. Kỹ sư phần mềm phải cư xử theo một cách trung thực và có trách nhiệm đạo đức nếu họ muốn được tôn trọng như các chuyên gia. Hành vi đạo đức không chỉ đơn giản là tuân theo pháp luật Trách nhiệm chuyên môn 27 Tính bảo mật (confidentiality) Các kỹ sư thường phải tôn trọng sự bảo mật của người sử dụng lao động hoặc khách hàng của họ bất kể một hợp đồng bảo mật chính thức có được ký kết hay không. Năng lực (competence) Các kỹ sư không nên làm sai lệch trình độ của mình. Họ không nên cố chấp nhận công việc vượt quá khả năng của mình. Quyền sở hữu trí tuệ (intellectual property rights) Các kỹ sư nên biết về luật pháp địa phương quy định việc sử dụng sở hữu trí tuệ như bằng sáng chế, bản quyền, Họ nên cẩn thận để đảm bảo rằng sở hữu trí tuệ của người sử dụng lao động và khách hàng được bảo vệ. Lạm dụng máy tính (computer misuse) KSPM không nên sử dụng kỹ năng của mình để lạm dụng máy tính của người khác. Lạm dụng máy tính bao gồm từ những việc tương đối tầm thường (như chơi game trên máy tính của người sử dụng lao động) đến những việc nghiêm trọng (như phát tán virus). Bộ Quy tắc Đạo đức ACM/IEEE 28 Các hiệp hội chuyên nghiệp ở Hoa Kỳ đã hợp tác để đưa ra một bộ quy tắc đạo đức (Code of Ethics) Thành viên của những tổ chức này đăng ký vào bộ quy tắc hành động khi họ gia nhập Bộ quy tắc bao gồm 8 nguyên tắc liên quan đến hành vi và quyết định tạo bởi những kỹ sư phần mềm chuyên nghiệp Bộ quy tắc đạo đức – 8 Nguyên tắc 29 1. CỘNG ĐỒNG (PUBLIC) Kỹ sư phần mềm (KSPM) phải hành động phù hợp với lợi ích cộng đồng 2. KHÁCH HÀNG VÀ NGƯỜI SỬ DỤNG LAO ĐỘNG (CLIENT & EMPLOYER) KSPM phải hành động cho lợi ích tốt nhất của khách hàng và người sử dụng lao động phù hợp với lợi ích cộng đồng 3. SẢN PHẨM (PRODUCT) KSPM phải đảm bảo rằng sản phẩm của họ và những thay đổi liên quan đáp ứng những chuẩn chuyên môn cao nhất có thể 4. ĐÁNH GIÁ (JUDGMENT) KSPM phải duy trì tính toàn vẹn và độc lập trong sự đánh giá chuyên nghiệp của mình 5. QUẢN LÝ (MANAGEMENT) Nhà quản lý và lãnh đạo CNPM phải đăng ký và thúc đẩy cách tiếp cận đạo đức đối với việc quản lý phát triển và bảo trì phần mềm 6. CHUYÊN NGHIỆP (PROFESSION) KSPM phải nâng cao tính toàn vẹn và uy tín nghề nghiệp phù hợp với lợi ích cộng đồng 7. ĐỒNG NGHIỆP (COLLEAGUES) KSPM phải công bằng và hỗ trợ đồng nghiệp của mình 8. BẢN THÂN (SELF) KSPM phải tham gia học tập suốt đời liên quan đến thực hành nghề nghiệp và thúc đẩy tiếp cận đạo đức đối với việc thực hành này Tình huống khó xử về đạo đức (Ethical dilemmas) 30 Sự không đồng thuận về nguyên tắc với chính sách quản lý cấp cao Người sử dụng lao động hành xử theo cách phi đạo đức và phát hành một hệ thống thiếu an toàn mà không hoàn thành việc thử nghiệm (testing) Tham gia phát triển những hệ thống vũ khí quân sự hoặc hệ thống hạt nhân Tóm tắt Công nghệ Phần mềm (1/2) 31 CNPM là một ngành kỹ thuật liên quan đến tất cả khía cạnh của sản phẩm phần mềm Sản phẩm phần mềm bao gồm các chương trình được phát triển và tài liệu liên quan. Những thuộc tính thiết yếu của sản phẩm là: tính bảo trì (maintainability), tính tin cậy (dependability), tính hiệu quả (efficiency) và tính sử dụng (usability) Các phương pháp là những cách tổ chức để sản xuất phần mềm. Chúng bao gồm: những đề xuất cho quá trình phải tuân theo, bộ ký hiệu sử dụng, những quy tắc chi phối việc miêu tả hệ thống được sản xuất và những hướng dẫn thiết kế Tóm tắt Công nghệ Phần mềm (2/2) 32 KSPM có những trách nhiệm đối với nghề nghiệp và cộng đồng. Họ không nên chỉ đơn giản liên quan với những vấn đề kỹ thuật Các hiệp hội chuyên nghiệp công bố bộ quy tắc ứng xử nhằm xác định những tiêu chuẩn hành vi mong muốn của những thành viên 3. Quản lý dự án Phần mềm Software Project Management 33 Mục tiêu 34 Giới thiệu quản lý dự án phần mềm và miêu tả những đặc điểm riêng biệt của nó Giải thích những tác vụ chính được thực hiện bởi những người quản trị dự án (project managers) Thảo luận về lập kế hoạch dự án và quá trình lập kế hoạch Chỉ ra bằng cách nào những biểu diễn lịch trình đồ họa (graphial schedule) được sử dụng để quản lý dự án Thảo luận những khái niệm về rủi ro (risk) và quá trình quản lý rủi ro Chủ đề được đề cập (Topics covered) 35 Những hoạt động quản lý (Management activities) Lập kế hoạch dự án (project planning) Lập lịch trình dự án (project scheduling) Quản lý rủi ro (risk management) Quản lý Dự án Phần mềm (Software project management) 36 Liên quan đến những hoạt động để đảm bảo rằng: phần mềm được phân phối đúng hạn (on time), theo đúng lịch trình (on schedule) và phù hợp với những yêu cầu của công ty phát triển cũng như công ty đặt hàng phần mềm Quản lý dự án là cần thiết do quá trình phát triển phần mềm luôn luôn phụ thuộc vào ngân sách và những rằng buộc lịch trình được đặt ra bởi công ty phát triển phần mềm Những Hoạt động Quản lý (Management activities) 37 Viết đề xuất (proposal writing) Lập kế hoạch và lịch trình dự án (project planning & scheduling) Lập chi phí dự án (project costing) Giám sát dự án và duyệt lại (project monitoring & reviews) Lựa chọn và đánh giá nhân sự (personnel selection & evaluation) Viết báo cáo và trình bày (report writing & presentations) Tính chất chung của Quản lý (Management commonalities) 38 Những hoạt động này không phải là đặc thù (peculiar) của quản lý phần mềm Nhiều kỹ thuật trong các ngành quản lý dự án khác đều có thể áp dụng cho quản lý dự án phần mềm Lập nhân dự dự án (Project staffing) 39 Có thể không thể bổ nhiệm những người lý tưởng để làm việc trong một dự án, do: Ngân sách dự án không cho phép sử dụng những nhân viên được trả lương cao Nhân sự với kinh nghiệm thích hợp có thể không sẵn có Công ty có thể mong muốn phát triển những kỹ năng cho nhân viên trong dự án phần mềm Nhà quản lý phải làm việc với những rằng buộc này, đặc biệt khi có tình trạng thiếu nhân sự được huấn luyện Lập kế hoạch dự án (Project planning) 40 Có thể là hoạt động quản lý dự án tốn nhiều thời gian nhất Là hoạt động liên tục từ lúc hình thành khái niệm ban đầu đến khi phân phối hệ thống. Những kế hoạch phải thường xuyên được sửa lại khi có thông tin mới Nhiều loại khác nhau của kế hoạch phải được phát triển để hỗ trợ kế hoạch dự án phần mềm chính, cái mà liên quan đến lịch trình và ngân sách dự án Các kiểu kế hoạch dự án 41 Kế hoạch Miêu tả Kế hoạch chất lượng (Quality plan) Miêu tả ... ất bởi KH Loại bỏ mẫu thử: mục đích là để tìm hiểu các yêu cầu của hệ thống Thường bắt đầu với những yêu cầu không rõ ràng và ít thông tin. Các mẫu thử sẽ được xây dựng và chuyển giao tới cho người sử dụng Từ đó có thể phân loại những yêu cầu nào là thực sự cần thiết và lúc này mẫu thử không còn cần thiết nữa Mô hình Phát triển Tiến hóa Minh họa 94 Mô hình Phát triển Tiến hóa Phân tích 95 Vấn đề Thiếu tầm nhìn của cả quy trình Hệ thống thường hướng cấu trúc nghèo nàn Yêu cầu những kỹ năng đặc biệt (ví dụ: về mặt ngôn ngữ để tạo nguyên mẫu nhanh) Tính ứng dụng: Cho những hệ thống tương tác vừa và nhỏ Cho những phần (module) của hệ thống lớn (ví dụ: giao diện người dùng) Cho những hệ thống có vòng đời ngắn Mô hình dựa trên thành phần (Component-based Software Engineering) 96 Dựa trên việc tái sử dụng có hệ thống, Hệ thống được tích hợp từ những thành phần sẵn có hoặc từ những hệ thống COTS (Commercial-off-the-shelf) Những giai đoạn: Phân tích thành phần Thay đổi yêu cầu Thiết kế hệ thống với việc sử dụng lại Phát triển và tích hợp Cách tiếp cận này đang ngày càng được sử dụng nhiều khi các tiêu chuẩn thành phần được đưa vào sử dụng Phát triển hướng Tái sử dụng (Reuse-oriented development) 97 Quy trình lặp (Process iteration) 98 Các yêu cầu hệ thống LUÔN LUÔN tiến hóa trong quá trình thực hiện dự án vì thế lặp quy trình luôn là một phần của quy trình cho những hệ thống lớn Quá trình lặp có thể được áp dụng với bất kỳ mô hình quy trình chung nào Hai cách tiếp cận liên quan Phân phối gia tăng (incremental delivery) Phát triển xoắn ốc (spiral development) Mô hình Bản mẫu (Prototyping Model) 99 Phân phối gia tăng (Incremental delivery) 100 Thay vì phát triển và phân phối hệ thống một lần, sự phát triển và phân phối được chia ra thành nhiều vòng, tăng dần, gọi là các gia số (increment) Mỗi gia số phân phối một tập con các chức năng được yêu cầu Những yêu cầu người dùng được sắp ưu tiên và yêu cầu ưu tiên cao nhất được bao gồm trong những gia số đầu tiên Phát triển gia tăng (Incremental development) 101 Phát triển gia tăng (Incremental development) 102 Phát triển gia tăng Ưu điểm 103 Khách hàng không phải đợi cho đến khi toàn bộ hệ thống được phân phối trước khi có thể thu được giá trị từ nó. Những gia số bước đầu giống như một nguyên mẫu để giúp phát hiện những yêu cầu cho những gia số bước sau Bản phát hành đầu tiên sẽ thỏa mãn hầu hết những yêu cầu quan trọng nhất của KH KH có thể sử dụng phần mềm ngay lập tức Những dịch vụ hệ thống có độ ưu tiên cao nhất được phân phối trước tiên, và có xu hướng nhận được kiểm thử nhiều nhất Nguy cơ thất bại toàn bộ dự án thấp hơn Mô hình phát triển xoắn ốc (Spiral development) 104 Được biểu diễn theo một hình xoắn ốc thay vì một chuỗi tuần tự những hành động với cơ chế truy vết ngược Mỗi vòng lặp trong sơ đồ xoắn ốc biểu diễn một pha của quy trình Không có những pha cố định như đặc tả hay thiết kế - những vòng lặp trong sơ đồ xoắn ốc được chọn dựa vào điều gì được yêu cầu Rủi ro được đánh giá và giải quyết trong suốt quy trình Những Hoạt động của Mô hình xoắn ốc (Spiral model sectors) 105 Thiết lập mục tiêu (objective setting) Các mục tiêu cụ thể của từng pha được xác định Đánh giá và giảm thiểu rủi ro Rủi ro được đánh giá và những hành động được đưa ra để giảm thiểu những rủi ro chính Phát triển và đánh giá Một mô hình phát triển cho hệ thống được chọn Lập kế hoạch Dự án được đánh giá và giai đoạn tiếp theo của vòng xoắn được lên kế hoạch Mô hình Xoắn ốc (Boehm – IEEE 1988) 106 Phát triển Phần mềm Linh hoạt (Agile Development) 107 SCRUM (1/2) SCRUM (2/2) Nhắc lại: Những Hoạt động chung trong Quy trình PM 110 Đặc tả phần mềm (software specification) Thiết kế và cài đặt phần mềm (software design and implementation) Xác thực phần mềm (software validation) Tiến hóa phần mềm (software evolution) Đặc tả Phần mềm (Software specification) 111 Quá trình thiết lập những dịch vụ gì được yêu cầu và những rằng buộc với thao tác và phát triển hệ thống Quy trình kỹ thuật tạo yêu cầu (requirements engineering process) Nghiên cứu khả thi (feasibility study) Đưa ra và Phân tích yêu cầu (requirements elicitation & analysis) Đặc tả yêu cầu (requirements specification) Xác thực yêu cầu (requirements validation) Yêu cầu kỹ thuật (Requirements engineering process) 112 Thiết kế và Cài đặt Phần mềm (Software design and implementation) 113 Là quá trình của việc chuyển những đặc tả hệ thống thành một hệ thống có thể chạy được Thiết kế phần mềm Thiết kế một cấu trúc phần mềm phù hợp với đặc tả Cài đặt phần mềm Chuyển cấu trúc này thành một chương trình có thể chạy được Những hoạt động thiết kế và cài đặt có liên hệ gần gũi với nhau và có thể đan xen Những Hoạt động trong Quá trình Thiết kế (Design process activities) 114 Thiết kế kiến trúc (architectural design) Đặc tả trừu tượng (abstract specification) Thiết kế giao diện (interface design) Thiết kế thành phần (component design) Thiết kế cấu trúc dữ liệu (data structure design) Thiết kế thuật toán (algorithm design) Quá trình Thiết kế Phần mềm (Software design process) 115 Những Phương pháp có cấu trúc (Structured methods) 116 Là những cách tiếp cận có hệ thống để phát triển một thiết kế phần mềm Thiết kế thường được tài liệu hóa như một tập các mô hình đồ họa Các mô hình có thể là: Mô hình đối tượng (object model) Mô hình trình tự (sequence model) Mô hình chuyển trạng thái (state transition model) Mô hình cấu trúc (structural model) Mô hình luồng dữ liệu (data-flow model) Lập trình và Gỡ rối (Programing and Debugging) 117 Là quá trình chuyển từ thiết kế thành chương trình và loại bỏ lỗi (errors) từ chương trình đó Lập trình là một hoạt động cá nhân – không có tiến trình lập trình chung Lập trình viên thực hiện một vài kiểm thử chương trình để phát hiện lỗi (faults) trong chương trình và loại bỏ những lỗi này trong quá trình gỡ rối (debugging) Quá trình Gỡ rối (Debugging process) 118 Xác thực Phần mềm (Software validation) 119 Xác minh và xác thực (verification & validation – V & V) được dự định để chỉ ra rằng một hệ thống phù hợp với đặc tả của nó và tuân theo những yêu cầu của khách hàng Liên quan đến việc kiểm tra và xem xét lại những quá trình và kiểm thử hệ thống Kiểm thử hệ thống liên quan đến chạy hệ thống với những trường hợp thử nghiệm (test cases), được bắt nguồn từ đặc tả của dữ liệu thật được xử lý bởi hệ thống Quy trình Kiểm thử (Testing process) 120 Những Giai đoạn Kiểm thử (Testing stages) 121 Kiểm thử thành phần hay kiểm thử đơn vị (Component or unit testing) Những thành phần cá nhân được kiểm thử độc lập Thành phần có thể là những hàm hoặc những đối tượng hoặc những nhóm kết hợp (coherent groups) của những thực thể này Kiểm thử hệ thống (System testing) Kiểm thử cả hệ thống như một toàn thể. Kiểm thử những đặc tính khẩn cấp (emergent properties) là cực kỳ quan trọng Kiểm thử chấp nhận (Acceptance testing) Kiểm thử với dữ liệu khách hàng để kiểm tra xem hệ thống có tuân theo những nhu cầu của khách hàng không Các pha Kiểm thử (Testing phases) 122 Giới thiệu về Mô hình RUP và công cụ CASE 123 RUP (1/2) (Rational Unified Process) 124 Một mô hình quy trình hiện đại xuất phát từ công việc trên UML và quá trình liên quan Thông thường RUP được miêu tả với 3 khía cạnh (perspectives) 1. Khía cạnh động (dynamic perspective): hiển thị những giai đoạn theo thời gian 2. Khía cạnh tĩnh (static perspective): hiển thị những hành động của quy trình 3. Khía cạnh thực hành (pratice perspective): gợi ý thực hành tốt RUP (2/2) 125 Mô hình giai đoạn của RUP 126 Cái giai đoạn của RUP 127 Khởi đầu (Inception) Thiết lập các trường hợp nghiệp vụ (business case) cho hệ thống Nghiên cứu (Elaboration) Phát triển hiểu biết về miền vấn đề (problem domain) và kiến trúc hệ thống Xây dựng (Construction) Thiết kế hệ thống, lập trình và kiểm thử Chuyển đổi (Transition) Triển khai (deploy) hệ thống trong môi trường vận hành của nó Thực hành với mô hình RUP (RUP good practice) 128 Phát triển phần mềm lặp nhiều lần Quản lý yêu cầu Sử dụng kiến trúc dựa trên thành phần Trực quan hóa mô hình phần mềm Xác thực chất lượng phần mềm Kiểm soát sự thay đổi với phần mềm Quy trình công việc tĩnh (1/2) (Static workflows) 129 Luồng công việc Miêu tả Mô hình hóa nghiệp vụ (Business modelling) Quy trình nghiệp vụ được mô hình hóa sử dụng các trường hợp nghiệp vụ (business use cases) Yêu cầu (requirements) Các tác nhân tương tác với hệ thống được xác định và các trường hợp (use cases) được phát triển để mô hình hóa yêu cầu hệ thống Phân tích và thiết kế (Analysis and design) Một mô hình thiết kế được tạo ra và tài liệu hóa sử dụng những mô hình kiến trúc, mô hình thành phần, mô hình đối tượng và mô hình tuần tự (sequence models) Cài đặt (Implementation) Những thành phần trong hệ thống được cài đặt và cấu trúc vào những hệ thống con. Quá trình sinh mã tự động từ những mô hình thiết kế giúp đẩy nhanh quá trình này Kiểm thử (Testing) Kiểm thử là một quá trình lặp lại, được tiến hành kết hợp với quá trình cài đặt. Kiểm thử hệ thống theo thực hiện sau khi hoàn thành việc cài đặt Triển khai (Deployment) Một bản phát hành của sản phẩm được tạo ra, phân phối tới người dùng và cài đặt vào nơi làm việc của họ Quy trình công việc tĩnh (2/2) (Static workflows) 130 Luồng công việc Miêu tả Quản lý cấu hình và sự thay đổi (Configuration and change management) Luồng công việc phụ trợ này quản lý những thay đổi của hệ thống Quản lý dự án (Project management) Luồng công việc phụ trợ này quản lý phát triển hệ thống Môi trường (Environment) Luồng công việc này liên quan đến việc tạo những công cụ phần mềm thích hợp sẵn sàng cho nhóm phát triển sử dụng CASE là gì? (1/2) (Computer-Aided Software Engineering) 131 CASE là những hệ thống phần mềm hỗ trợ cho quá trình phát triển và tiến hóa phần mềm Tự động hóa hoạt động (activity automation) Trình soạn thảo bằng đồ họa (graphical editors) cho quá trình phát triển mô hình hệ thống Từ điển dữ liệu (data dictionary) để quản lý những thực thể trong thiết kế (design entities) Trình tạo giao diện đồ họa (graphical UI builder) cho việc xây dựng giao diện người dùng Trình gỡ rối (debuggers) để hỗ trợ việc tìm lỗi chương trình (program fault) Trình dịch tự động (automated translators) để tạo những phiên bản mới cho chương trình CASE là gì? (2/2) (Computer-Aided Software Engineering) 132 CASE thường được dùng cho hỗ trợ phương pháp Upper-CASE: Những công cụ hỗ trợ những hành động tiến trình ở giai đoạn đầu: xác định yêu cầu (requirements) và thiết kế (design) Lower-CASE: Những công cụ hỗ trợ những hành động ở giai đoạn sau như: lập trình (programming), debugging và testing Công nghệ CASE 133 Công nghệ CASE dẫn tới những cải tiến đáng kể trong tiến trình phần mềm. Tuy nhiên đây không phải là những cải tiến lớn như đã từng được dự đoán Công nghệ phần mềm đòi hỏi phải có tư duy sáng tạo – điều này không dễ dàng có thể được tự động hóa Công nghệ phần mềm là một hoạt động nhóm và với những dự án lớn, phải sử dụng nhiều thời gian trong việc tương tác nhóm. Công nghệ CASE không thực sự hỗ trợ điều này Phân loại CASE (CASE classification) 134 Sự phân loại giúp chúng ta hiểu những kiểu khác nhau của công cụ CASE và những hỗ trợ của chúng cho hoạt động tiến trình Khía cạnh chức năng (functional perspective) Phân loại dựa theo chức năng cụ thể của chúng Khía cạnh quy trình (process perspective) Phân loại dựa theo những hoạt động quy trình được hỗ trợ Khía cạnh tích hợp (integration perspective) Phân loại dựa theo tổ chức của chúng trong những đơn vị được tích hợp Phân loại công cụ chức năng (1/2) (Functional tool classification) 135 Kiểu công cụ Ví dụ Công cụ lập kế hoạch Công cụ PERT, công cụ ước lượng, bảng tính (spreadsheet) Công cụ soạn thảo Trình soạn thảo văn bản, biểu đồ, bộ xử lý từ ngữ Công cụ quản lý sự thay đổi Công cụ truy xuất yêu cầu, hệ thống kiểm soát sự thay đổi Công cụ quản lý cấu hình Hệ thống quản lý phiên bản, công cụ xây dựng hệ thống Công cụ tạo nguyên mẫu Ngôn ngữ ở mức rất cao, bộ tạo giao diện người dùng Ngôn ngữ hỗ trợ phương thức Trình thiết kế, từ điển dữ liệu, bộ sinh mã Công cụ xử lý ngôn ngữ Trình biên dịch (compilers), trình thông dịch (interpreters) Công cụ phân tích chương trình Bộ tạo tham chiếu chéo, trình phân tích tĩnh, trình phân tích động Phân loại công cụ chức năng (2/2) (Functional tool classification) 136 Kiểu công cụ Ví dụ Công cụ kiểm thử Bộ tạo dữ liệu kiểm thử, trình so sánh tệp tin Công cụ gỡ rối Hệ thống gỡ rối tương tác Công cụ tài liệu hóa Chương trình bố trí trang, trình xử lý hình ảnh Công cụ tái kỹ thuật Hệ thống tham chiếu chéo, hệ thống tái cấu trúc chương trình Phân loại công cụ dựa trên hành động (Activity-based tool classification) 137 Tích hợp CASE (CASE integration) 138 Công cụ Hỗ trợ những tác vụ quy trình cá nhân như kiểm tra tính nhất quán của thiết kế, soạn thảo văn bản, Workbench Hỗ trợ một giai đoạn quy trình như đặc tả, thiết kế. Thường bao gồm một số lượng công cụ được tích hợp Môi trường Hỗ trợ tất cả hoặc phần lớn của toàn bộ quy trình phần mềm. Thường bao gồm nhiều workbench được tích hợp Công cụ, Workbench, Môi trường 139 Tóm tắt Quy trình Phần mềm (1/2) (Key points) 140 Quy trình phần mềm là những hoạt động liên quan đến việc tạo ra và tiến hóa một hệ thống phần mềm Mô hình quy trình phần mềm là những biểu diễn trừu tượng của những quy trình này Những hoạt động chung là: đặc tả, thiết kế và cài đặt, xác thực và tiến hóa Những mô hình quy trình chung miêu tả tổ chức của những quy trình phần mềm. Ví dụ: mô hình thác nước, mô hình phát triển tiến hóa và mô hình kỹ thuật phần mềm dựa trên thành phần Những mô hình quy trình lặp miêu tả tiến trình phần mềm như một vòng tròn của những hành động Tóm tắt Quy trình Phần mềm (2/2) (Key points) 141 Kỹ thuật tạo yêu cầu là một quá trình của việc phát triển đặc tả phần mềm Quá trình thiết kế và cài đặt chuyển đổi đặc tả thành một chương trình có thể chạy được Xác thực (validation) liên quan đến đảm bảo rằng hệ thống đáp ứng đặc tả của nó và yêu cầu người dùng Tiến hóa liên quan đến thay đổi hệ thống sau khi nó đã đi vào hoạt động RUP là một mô hình quy trình chung để phân chia các hành động theo các giai đoạn Công cụ CASE là những hệ thống phần mềm được thiết kế để hỗ trợ những hoạt động thông thường trong quy trình phần mềm như: soạn thảo sơ đồ thiết kế, kiểm tra tính nhất quán của sơ đồ, lưu vết những thử nghiệm chương trình được chạy Tài liệu Tham khảo 142 Giáo trình chính: Software Engineering, Ian Sommerville, 8th Edition, 2007 Tham khảo: Object-Oriented Software Engineering Practical Software Development using UML and Java, Lloseng.com, Lethbridge/Laganièr,2001 Bài giảng & Tài liệu của môn Nhập Môn Công Nghệ Phần Mềm, PhạmThị Quỳnh
File đính kèm:
- bai_giang_cong_nghe_phan_mem_bai_1_ngon_ngu_lap_trinh_le_ngu.pdf