BÀI GIẢNG NHẬP MÔN CÔNG NGHỆ PHẦN MỀM

Khi đọc qua tài liệu này, phát sai sót nội dung chất lượng xin thông báo để sửa chữa thay tài liệu chủ đề tác giả khác Tài li u bao g m nhi u tài li u nh có ch đ bên Ph n n i dung b n c n có th n m gi a ho c cu i tài li u này, s d ng ch c Search đ tìm chúng Bạn tham khảo nguồn tài liệu dịch từ tiếng Anh đây: http://mientayvn.com/Tai_lieu_da_dich.html Thông tin liên hệ: Yahoo mail: thanhlam1910_2006@yahoo.com Gmail: frbwrthes@gmail.com Khi đọc qua tài liệu này, phát sai sót nội dung chất lượng xin thông báo để sửa chữa thay tài liệu chủ đề tác giả khác Tài li u bao g m nhi u tài li u nh có ch đ bên Ph n n i dung b n c n có th n m gi a ho c cu i tài li u này, s d ng ch c Search đ tìm chúng Bạn tham khảo nguồn tài liệu dịch từ tiếng Anh đây: http://mientayvn.com/Tai_lieu_da_dich.html Thông tin liên hệ: Yahoo mail: thanhlam1910_2006@yahoo.com Gmail: frbwrthes@gmail.com TRƢỜNG ĐẠI HỌC HÀNG HẢI VIỆT NAM KHOA CÔNG NGHỆ THÔNG TIN BỘ MÔN HỆ THỐNG THÔNG TIN -*** - BÀI GIẢNG NHẬP MÔN CÔNG NGHỆ PHẦN MỀM TÊN HỌC PHẦN MÃ HỌC PHẦN TRÌNH ĐỘ ĐÀO TẠO DÙNG CHO SV NGÀNH : CÔNG NGHỆ PHẦN MỀM : 17404 : ĐẠI HỌC CHÍNH QUY : CÔNG NGHỆ THÔNG TIN HẢI PHÒNG - 2011 MỤC LỤC Nội dung Chƣơng 1: Giới thiệu 1.1 Khái niệm phần mềm 1.2 Các đặc điểm phần mềm 1.3 Các ứng dụng phần mềm 1.4 Giới thiệu Công nghệ phần mềm (Software engineering) Chƣơng 2: Các mô hình phát triển phần mềm 2.1 Mô hình thác nước (Waterfall model) 2.2 Mô hình nguyên mẫu (Prototyping model) 2.3 Mô hình phát triển nhanh (RAD model) 2.4 Mô hình tăng trưởng (Incremental model) 2.5 Mô hình xoắn ốc (Spiral model) 2.6 Các mô hình đại (Fourth generation techniques) Chƣơng 3: Khảo sát phân tích yêu cầu 3.1 Thu thập yêu cầu (Requirements elicitation) 3.2 Phân tích yêu cầu (Requirements analysis) 3.3 Đặc tả yêu cầu (Requirements specification) 3.4 Xét duyệt yêu cầu (Requirements validation) Chƣơng 4: Mô hình hóa hệ thống 4.1 Mô hình hóa liệu (Data modeling) 4.2 Mô hình hóa chức (Functional modeling) 4.3 Mô hình hóa luồng thông tin (Information flow modeling) Chƣơng 5: Thiết kế hệ thống 5.1 Quá trình thiết kế (Design process) 5.2 Các nguyên tắc thiết kế (Design principles) Chƣơng 6: Kiểm thử phần mềm 6.1 Mục đích (Testing objectives) 6.2 Nguyên tắc kiểm thử (Testing principles) 6.3 Kiểm thử theo đường (Basic path) 6.4 Kiểm thử theo phân vùng tương đương (Equivalence partitioning) 6.5 Kiểm thử theo giá trị biên (Boundary value analysis) 6.6 Các mức độ kiểm thử (Testing strategy) Trang 5 9 11 13 13 13 15 18 18 28 28 35 37 37 37 38 40 43 46 50 50 50 50 54 56 58 Tên học phần: Nhập môn Công nghệ phần mềm Loại học phần: Bộ môn phụ trách giảng dạy: Hệ thống Thông tin Khoa phụ trách: CNTT Mã học phần: 17404 Tổng số TC: Tổng số tiết Lý thuyết Thực hành/Xemina Tự học Bài tập lớn Đồ án môn học 30 30 0 không không Học phần học trƣớc: Không yêu cầu Học phần tiên quyết: Không yêu cầu Học phần song song: Không yêu cầu Mục tiêu học phần: Cung cấp cho sinh viên kiến thức công nghệ phần mềm Nội dung chủ yếu: Giới thiệu công nghệ phần mềm; Các mô hình phát triển phần mềm; Lượng giá dự án phần mềm; Khảo sát phân tích yêu cầu; Mô hình hóa hệ thống; Thiết kế hệ thống; Kiểm thử phần mềm Nội dung chi tiết: TÊN CHƢƠNG MỤC PHÂN PHỐI SỐ TIẾT TS LT TH BT KT Chƣơng 1: Giới thiệu 1.1 Khái niệm phần mềm 1.2 Các đặc điểm phần mềm 1.3 Các ứng dụng phần mềm 1.4 Giới thiệu Công nghệ phần mềm (Software engineering) Chƣơng 2: Các mô hình phát triển phần mềm 2.1 Mô hình thác nước (Waterfall model) 2.2 Mô hình nguyên mẫu (Prototyping model) 2.3 Mô hình phát triển nhanh (RAD model) 2.4 Mô hình tăng trưởng (Incremental model) 2.5 Mô hình xoắn ốc (Spiral model) 2.6 Các mô hình đại (Fourth generation techniques) Chƣơng 3: Khảo sát phân tích yêu cầu 3.1 Thu thập yêu cầu (Requirements elicitation) 3.2 Phân tích yêu cầu (Requirements analysis) 3.3 Đặc tả yêu cầu (Requirements specification) 3.4 Xét duyệt yêu cầu (Requirements validation) Chƣơng 4: Mô hình hóa hệ thống 4.1 Mô hình hóa liệu (Data modeling) 4.2 Mô hình hóa chức (Functional modeling) 4.3 Mô hình hóa luồng thông tin (Information flow modeling) Chƣơng 5: Thiết kế hệ thống 5.1 Quá trình thiết kế (Design process) 5.2 Các nguyên tắc thiết kế (Design principles) 5.3 Các khái niệm thiết kế phần mềm (Design concepts) Chƣơng 6: Kiểm thử phần mềm 6.1 Mục đích (Testing objectives) 6.2 Nguyên tắc kiểm thử (Testing principles) 6.3 Kiểm thử theo đường (Basic path) 6.4 Kiểm thử theo phân vùng tương đương (Equivalence partitioning) 2 6 4 4 4 6 TÊN CHƢƠNG MỤC PHÂN PHỐI SỐ TIẾT TS LT TH BT KT 6.5 Kiểm thử theo giá trị biên (Boundary value analysis) 6.6 Các mức độ kiểm thử (Testing strategy) Nhiệm vụ sinh viên: Tham dự buổi học lý thuyết thực hành, làm tập giao, làm thi kỳ thi kết thúc học phần theo quy định Tài liệu học tập: Roger S Pressman, Software Engineering- A practitioner's Approach, 6th edition, McGrawHill Sommerville, Software Engineering, 7th edition, Pearson education Nguyễn Xuân Huy, Giáo trình công nghệ phần mềm, NXB Trường ĐHBK Hà Nội, 1996 Hình thức tiêu chuẩn đánh giá sinh viên: - Hình thức thi: tự luận trắc nghiệm - Tiêu chuẩn đánh giá sinh viên: vào tham gia học tập sinh viên buổi học lý thuyết thực hành, kết làm tập giao, kết thi học phần thi kết thúc học phần Thang điểm: Thang điểm chữ A, B, C, D, F Điểm đánh giá học phần: Z = 0,2X + 0,8Y Bài giảng tài liệu thức thống Bộ môn Hệ thống Thông tin, Khoa Công nghệ Thông tin dùng để giảng dạy cho sinh viên Ngày phê duyệt: Trƣởng Bộ môn / / Là tập hợp chương trình viết để phục vụ cho chương trình khác Chương trình xử lý thông tin phức tạp xác định cấp thấp, tạo môi trường hoạt động (trình biên dịch, trình soạn thảo, quản lý tệp tin, …) Các chương trình đặc trưng tương tác chủ yếu với phần cứng máy tính, phục vụ nhiều người dùng, có cấu trúc liệu phức tạp nhiều giao diện Nhóm 2: Phần mềm thời gian thực Là phần mềm điều phối phân tích hay kiểm soát kiện giới thực chúng xuất Phần mềm thời gian thực bao gồm yếu tố:  Một thành phần thu thập liệu để thu định dạng thông tin từ bên  Một thành phần phân tích để biến đổi thông tin theo yêu cầu ứng dụng  Một thành phần kiểm soát đưa đáp ứng cho môi trường  Một thành phần điều phối để điều hoà thành phần khác cho trì việc đáp ứng thời gian thực Hệ thống thời gian thực phải đáp ứng ràng buộc thời gian chặt chẽ Nhóm 3: Phần mềm nghiệp vụ Ngày nay, xử lý thông tin nghiệp vụ lĩnh vự ứng dụng phần mềm lớn Phần mềm loại phục vụ cho hệ thống rời rạc: hệ thông tin quản lý Các ứng dụng phần mềm nghiệp vụ bao gồm tính toán tương tác (như xử lý giao tác cho điểm bán hàng) ứng dụng xử lý liệu Nhóm 4: Phần mềm khoa học công nghệ Phần mềm đặc trưng thuật toán Phần mềm tạo ứng dụng mới, thiết kế có máy tính trợ giúp (computer aided of design - CAD), có ý đến đặc trưng thời gian thực phần mềm hệ thống Nhóm 5: Phần mềm nhúng Nằm nhớ đọc dùng để điều khiển sản phẩm hệ thống cho người dùng thị trường công nghiệp Có thể thực chức đơn giản mang tính chuyên biệt (huyền bí), ví dụ: điều khiển chức cho lò vi sóng; hay đưa khả điều khiển vận hành (chức số hoá ô-tô, kiểm soát xăng, biểu thị bảng đồng hồ, hệ thống phanh…) Nhóm 6: Phần mềm máy tính cá nhân Loại phần mềm bùng nổ thập kỷ vừa qua (như xử lý văn bản, trang tính, đồ hoạ, quản trị sở liệu) Hiện tiếp tục phát triển biểu thị giao diện người máy, tạo thân thiện, dễ sử dụng cho người dùng Nhóm 7: Phần mềm trí tuệ nhân tạo 10 Thiết kế Thiết kế phần mềm thực tế tiến trình nhiều bước tập trung vào bốn thuộc tính phân biệt chương trình: cấu trúc liệu, kiến trúc phần mềm, biểu diễn giao diện chi tiết thủ tục (thuật toán) Tiến trình thiết kế dịch yêu cầu thành biểu diễn phần mềm định giá chất lượng trước giai đoạn mã hoá bắt đầu Giống yêu cầu, việc thiết kế phải lập tư liệu trở thành phần cấu hình phần mềm Sinh mã Thiết kế phải dịch thành dạng máy đọc Bước mã hoá thực nhiệm vụ Nếu thiết kế thực theo cách chi tiết việc sinh mã thực cách máy móc Kiểm thử Một mã sinh việc kiểm thử chương trình bắt đầu Tiến trình kiểm thử hội tụ vào nội logic phần mềm, đảm bảo tất câu lệnh kiểm thử, vào bên chức năng; tức tiến hành kiểm thử để làm lộ lỗi đảm bảo vào định tạo kết thống với kết muốn có Vận hành bảo trì Phần mềm chắn phải trải qua thay đổi sau bàn giao cho khách hàng (một ngoại lệ phần mềm nhúng) Thay đổi xuất gặp phải lỗi, phần mềm phải thích ứng với thay đổi môi trường bên (chẳng hạn thay đổi hệ điều hành hay thiết bị ngoại vi mới), hay khách hàng yêu cầu nâng cao chức hay hiệu Việc bảo trì phần mềm phải áp dụng lại bước vòng đời nói cho chương trình chương trình Mô hình tuyến tính mô hình cũ sử dụng rộng rãi cho kĩ nghệ phần mềm Tuy nhiên, trích mô hình làm cho người ủng hộ tích cực phải đặt vấn đề tính hiệu Một số vấn đề gặp phải dùng mô hình tuyến tính là: Các dự án thực tuân theo dòng chảy mà mô hình đề nghị Mặc dầu mô hình tuyến tính cho phép lặp, điều làm gián tiếp Kết thay đổi gây lẫn lộn tổ dự án tiến hành Khách hàng thường khó phát biểu yêu cầu cách tường minh Mô hình tuyến tính đòi hỏi điều thường khó thích hợp với bất trắc tự nhiên tồn vào lúc đầu nhiều dự án Khách hàng phải kiên nhẫn Bản làm việc chương trình có vào lúc cuối thời gian dự án Một sai lầm ngớ ngẩn, đến có chương trình làm việc phát ra, thảm hoạ Trong phân tích thú vị dự án tại, Brada thấy chất tuyến tính vòng đời cổ điển dẫn tới "các trạng thái nghẽn" mà số thành viên tổ dự án phải đợi cho thành viên khác tổ hoàn thành nhiệm vụ phụ thuộc Trong thực tế, thời gian cho việc chờ đợi vượt thời gian dành cho công việc sản xuất Trạng thái nghẽn có khuynh hướng phổ biến vào lúc đầu cuối tiến trình tuyến tính 12 có hay áp dụng công cụ (như sinh báo cáo, quản lí cửa sổ, v.v ) để nhanh chóng sinh chương trình làm việc Nhưng nghĩ mẫu dùng cho mục đích nêu trên? Brook nêu câu trả lời: Trong hầu hết dự án, hệ thống sử dụng Nó chậm, lớn, cồng kềnh sử dụng hay tất nhược điểm Không có cách khác bắt đầu lại, đau đớn tinh khôn hơn, xây dựng phiên thiết kế lại vấn đề giải Khi khái niệm hệ thống hay kĩ nghệ dùng, người ta phải xây dựng hệ thống để vứt đi, cho dù việc lập kế hoạch thực chu đáo bao quát hết để chạy lần đầu Do câu hỏi quản lí liệu có nên xây dựng hệ thống thử nghiệm vứt hay không Bạn làm Câu hỏi liệu nên lập kế hoạch trước để xây dựng vứt hay để hứa hẹn bàn giao vứt cho khách hàng Bản mẫu phục vụ "hệ đầu tiên" - mà Brook lưu ý nên vứt Nhưng điều cách nhìn lí tưởng hoá Giống mô hình tuyến tính (thác nước), việc làm mẫu tựa mô hình cho kĩ nghệ phần mềm trở thành có vấn đề lí sau: Khách hàng thấy dường phiên làm việc phần mềm mà mẫu gắn lại "bằng kẹo cao su dây gói hàng", xô đẩy làm việc chẳng xem xét tới chất lượng phần mềm tổng thể hay tính bảo trì thời gian dài Khi thông báo sản phẩm phải xây dựng lại đạt tới mức độ chất lượng cao, khách hàng kêu trời đòi hỏi "phải sửa chữa" để làm mẫu thành sản phẩm làm việc Rất thường việc quản lí phát triển phần mềm bị buông lỏng Người phát triển thường hay thoả hiệp cài đặt để có mẫu làm việc nhanh chóng Hệ điều hành hay ngôn ngữ lập trình không thích hợp dùng đơn giản có sẵn biết; thuật toán không hiệu cài đặt đơn giản để chứng tỏ khả Sau thời gian, người phát triển trở nên quen thuộc với chọn lựa quên lí chúng lại không thích hợp Việc chọn lựa không theo lí tưởng lại trở thành phần tích hợp hệ thống Mặc dầu vấn đề xuất hiện, việc làm mẫu mô hình hiệu cho kĩ nghệ phần mềm Chìa khoá định nghĩa qui tắc trò chơi từ lúc bắt đầu; tức khách hàng người phát triển phải đồng ý mẫu xây dựng để phục vụ làm chế xác định yêu cầu Thế phải bị bỏ (ít phần) phần mềm thực đưa vào kĩ nghệ với mắt hướng chất lượng tính bảo trì 14 Đánh giá khánh hàng - nhiệm vụ đòi hỏi thu phản hồi khách hàng dựa đánh giá biểu diễn phần mềm tạo giai đoạn kĩ nghệ cài đặt giai đoạn cài đặt Mỗi vùng đặt vào tập nhiệm vụ, gọi tập nhiệm vụ, vốn thích ứng với đặc trưng dự án tiến hành Với án nhỏ, số nhiệm vụ công việc tính hình thức chúng thấp Với dự án lớn, nhiều căng thẳng hơn, vùng nhiệm vụ lại chứa nhiều nhiệm vụ công việc vốn xác định để đạt tới mức độ hình thức cao Trong trường hợp, hoạt động hỗ trợ (như quản lí cấu hình phần mềm đảm bảo chất lượng phần mềm) - nêu phần sau - áp dụng Khi tiến trình tiến hoá bắt đầu, tổ kĩ nghệ phần mềm vòng xoắn ốc theo chiều ngược kim đồng hồ, trung tâm Mạch quanh xoắn ốc làm phát sinh việc phát triển đặc tả sản phẩm; bước quanh xoắn ốc dùng để phát triển mẫu phiên phức tạp dần thêm Mỗi bước qua vùng lập kế hoạch lại làm nảy sinh việc điều chỉnh kế hoạch dự án Chi phí lịch biểu điều chỉnh dựa phản hồi suy từ đánh giá khách hàng Bên cạnh đó, người quản lí dự án điều chỉnh số việc lặp lập kế hoạch cần để hoàn chỉnh phần mềm Trao đổi với khách hàng Trục điểm vào dự án Lập kế hoạch Phân tích rủi ro Đánh giá khách hàng Xây dựng đưa Kĩ ngh ệ Dự án bảo trì sảnán phẩm Dự nâng caoán sản phẩm Dự phát triển sản phẩm Dự phát triển Không giống mô hình tiếnán trình cổmới điển vốn kết thúc phần mềm chuyển giao, khái niệm mô hình xoắn ốc thích ứng để áp dụng toàn đời phần mềm máy tính Một nhìn khác xem xét việc kiểm tra trục điểm vào dự án, vẽ hình Mỗi hình hộp đặt theo trục dùng để biểu diễn cho điểm bắt đầu cho kiểu dự án khác "Dự án phát triển khái niệm" bắt đầu cốt lõi xoắn ốc tiếp tục (nhiều lần lặp xuất theo đường xoắn ốc mà vốn gắn với vùng tô đậm trung tâm) việc phát triển khái niệm đầy đủ Nếu khái niệm phát triển thành sản phẩm thực tại, Mô hình xoắn ốc (spiral) Lập kế hoạch Phân tích rủi ro Giao tiếp khách hàng Khái niệm Kỹ nghệ Làm Nâng cấp Bảo trì HUT, Falt of IT Khách hàng đánh giá Dept of SE, 2001 Xây dựng & Xuất xưởng SE-I.101 Mô hình xoắn ốc (tiếp) • Giao tiếp khách hàng: người phát triển khách hàng để tìm hiểu yêu cầu, ý kiến • Lập kế hoạch: Xác lập tài nguyên, thời hạn thông tin khác • Phân tích rủi ro: Xem xét mạo hiểm kỹ thuật mạo hiểm quản lý • Kỹ nghệ: Xây dựng hay số biểu diễn ứng dụng HUT, Falt of IT Dept of SE, 2001 SE-I.102 Mô hình xoắn ốc (tiếp) • Xây dựng xuất xưởng: 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, ) • Đánh giá khách hàng: Nhận phản hồi người sử dụng biểu diễn phần mềm giai đoạn kỹ nghệ cài đặt HUT, Falt of IT Dept of SE, 2001 SE-I.103 Mô hình xoắn ốc: Mạnh yếu? • Tốt cho hệ phần mềm quy mô lớn • Dễ kiểm soát mạo hiểm mức tiến hóa • Khó thuyết phục khách hàng phương pháp tiến hóa xoắn ốc kiểm soát • Chưa dùng rộng rãi mô hình tuyến tính chế thử HUT, Falt of IT Dept of SE, 2001 SE-I.104 Mô hình xoắn ốc WINWIN • Nhằm thỏa hiệp người phát triển khách hàng, hai “Thắng” (win-win) – Khách có phần mềm thỏa mãn yêu cầu – Người phát triển có kinh phí thỏa đáng thời gian hợp lý • Các hoạt động xác định hệ thống: – Xác định cổ đông (stakeholders) – Xác định điều kiện thắng cổ đông – Thỏa hiệp điều kiện thắng bên liên quan HUT, Falt of IT Dept of SE, 2001 SE-I.105 Mô hình xoắn ốc WINWIN Xác định điều kiện thắng cổ đông 3a Hòa hợp điều kiện thắng 3b Thiết lập mục tiêu mức tiếp ràng buộc, dự kiến Xác định mức tiếp cổ đông Đánh giá tiến trình dự kiến sản phẩm, giải rủi ro Xét duyệt đánh giá Kiểm định sản phẩm quy trình HUT, Falt of IT Dept of SE, 2001 Xác định mức tiếp sản phâm quy trình, kể phân chia nhỏ SE-I.106 Mô hình phát triển đồng thời (The concurrent development model) • Xác định mạng lưới hoạt động đồng thời (Network of concurrent activities) • Các kiện (events) xuất theo điều kiện vận động trạng thái hoạt động • Dùng cho loại ứng dụng cho hình ảnh xác trạng thái trạng dự án • Thường dùng phát triển ứng dụng khách/chủ (client/server applications): system and componets are developed concurrently HUT, Falt of IT Dept of SE, 2001 SE-I.107 3.5.6 Mô hình theo thành phần (Component-based model) • Gắn với công nghệ hướng đối tượng (Objectoriented technologies) qua việc tạo lớp (classes) có chứa liệu giải thuật xử lý liệu • Có nhiều tương đồng với mô hình xoắn ốc • Với ưu điểm tái sử dụng thành phần qua Thư viện / kho lớp: tiết kiệm 70% thời gian, 80% giá thành, số sản xuất 26.2/16.9 • Với UML chuẩn công nghiệp triển khai HUT, Falt of IT Dept of SE, 2001 SE-I.108 Mô hình theo thành phần Lập kế hoạch Phân tích rủi ro Giao tiếp khách hàng Khách hàng đánh giá HUT, Falt of IT Xác định thành phần ứng viên Xây dựng bước lặp thứ n hệ thống Kỹ nghệ Xây dựng & Xuất xưởng Dept of SE, 2001 Đặt thành phần vào thư viện Tìm thành phần từ thư viện Lấy thành phần có Xây dựng thành phần kh.có SE-I.109 3.5.7 Mô hình hình thức (Formal model) • Còn gọi CNHPM phòng (Cleanroom SE) • Tập hợp công cụ nhằm đặc tả toán học phần mềm máy tính từ khâu định nghĩa, phát triển đến kiểm chứng • Giúp kỹ sư phần mềm phát sửa lỗi khó • Thường dùng phát triển SW cần độ an toàn cao (y tế, hàng không, ) HUT, Falt of IT Dept of SE, 2001 SE-I.110 Mô hình hình thức: Điểm yếu ? • Cần nhiều thời gian công sức để phát triển • Phí đào tạo cao người có cho áp dụng mô hình hình thức • Khó sử dụng rộng rãi cần kiến thức toán kỹ khách hàng HUT, Falt of IT Dept of SE, 2001 SE-I.111 3.5.8 Các kỹ thuật hệ (Fourth generation techniques) • Tập hợp công cụ cho phép xác định đặc tính phần mềm mức cao, sau sinh tự động mã nguồn dựa theo đặc tả • Các công cụ 4GT điển hình: ngôn ngữ phi thủ tục cho truy vấn CSDL; tạo báo cáo; xử lý liệu; tương tác hình; tạo mã nguồn; khả đồ họa bậc cao; khả bảng tính; khả giao diện Web; vv HUT, Falt of IT Dept of SE, 2001 SE-I.112 4GT: How ? • Từ thu thập yêu cầu sản phẩm: đối thoại khách người phát triển quan trọng • Không nên bỏ qua khâu thiết kế 4GT áp dụng để triển khai thiết kế qua 4GL • Mạnh: giảm thời gian phát triển tăng suất • Yếu: 4GT khó dùng ngôn ngữ lập trình, mã khó tối ưu khó bảo trì cho hệ thống lớn cần kỹ kỹ sư phần mềm • Tương lai: 4GT với mô hình theo thành phần HUT, Falt of IT Dept of SE, 2001 SE-I.113 3.5.9 Sản phẩm quy trình (Product and process) • Quy trình yếu sản phẩm khó mà tốt, song không nên coi trọng mức vào quy trình mức vào sản phẩm • Sản phẩm quy trình cần coi trọng HUT, Falt of IT Dept of SE, 2001 SE-I.114 Bài tập Phần I Đồ án I • Xem lại khái niệm, mô hình phần mềm CNHPM • Đồ án môn học I (cho 13 nhóm, nạp báo cáo, tư liệu tìm Web thư viện): – Tìm hiểu viết báo cáo, trình bày mô hình phát triển phần mềm (10 mô hình / 10 nhóm) – Chuẩn ISO 9001 cho SE – Chuẩn CMM (www.sei.com) – Các kỹ thuật lập trình (cấu trúc, mô đun, ) HUT, Falt of IT Dept of SE, 2001 SE-I.115