NHỮNG VẤN ĐỀ PHƯƠNG PHÁP LUẬN CƠ BẢN 1. Một số khái niệm cơ bản về thiết kế và xây dựng phần mềm 1.1 Khái niệm về phần mềm. Hiện nay có khá nhiều cách định nghĩa phần mềm phụ thuộc vào cách tiếp cận với hệ thống. Theo cách tiếp cận đơn giản nhất có thể xem phần mềm bao gồm các câu lệnh và các cấu trúc dữ liệu thích hợp để thực hiện những chức năng mong muốn; và các tài liệu mô tả thao tác và cách sử dụng chương trình. - Xét theo nghĩa rộng hơn, phần mềm là tất cả các kỹ thuật làm cho việc sử dụng phần cứng máy tính đạt hiệu quả cao,bao gồm: • Nhóm các kỹ thuật, phương pháp luận: Các khái niệm, các trình tự thiết kế và phát triển, các phương pháp tiếp cận vấn đề, đặc tả yêu cầu, thiết kế hệ thống, kiểm thử, . • Nhóm các chương trình: bao gồm các câu lệnh và các cấu trúc dữ liệu thích hợp để thực hiện những chức năng mong muốn. Phần mềm có hai loại là phần mềm cơ bản và phần mềm ứng dụng. Phần mềm cơ bản có chức năng cung cấp môi trường thao tác dễ dàng cho người sử dụng nhằm tăng hiệu năng xử lý của phần cứng. Phần mềm ứng dụng dùng để xử lý nghiệp vụ thích hợp nào đó. • Nhóm các tài liệu: Gồm các tư liệu mô tả thao tác và cách sử dụng chương trình và một số tài liệu khác: điều kiện kiểm thử, vận hành, bảo trì… Nhóm các kỹ thuật, phương pháp luận Nhóm các chương trình Nhóm các tư liệu Kinh nghiệm kỹ sư, know-how • Các kinh nghiệm, khả năng, kỹ năng của kỹ sư (know-how) Hình 2: Mô hình phần mềm 1.2. Đặc tính chung của phần mềm • Phần mềm là hàng hóa vô hình • Chất lượng phần mềm: không giảm đi mà có xu hướng tốt lên sau mỗi lần có lỗi (error/bug) được phát hiện và sửa • Phần mềm vốn chứa lỗi tiềm tàng, quy mô phần mềm càng lớn thì khả năng chứa lỗi càng cao • Lỗi phần mềm thường dễ được phát hiện bởi người ngoài • Chức năng của phần mềm thường thay đổi theo thời gian và theo nơi sử dụng • Hiệu ứng làn sóng trong thay đổi phần mềm • Phần mềm vốn chứa ý tưởng và sáng tạo của tác giả/nhóm tác giả làm ra nó • Trong xây dựng, phát triển phần mềm cần khả năng “tư duy nhị phân” • Phần mềm có thể sao chép rất đơn giản 1.3. Vòng đời phát triển của phần mềm Vòng đời phần mềm là khoảng thời gian tính từ khi phần mềm được tạo ra cho đến khi chết đi (tức là từ lúc hình thành đáp ứng yêu cầu, vận hành, bảo dưỡng cho đến khi loại bỏ không dùng nữa) Vòng đời phần mềm chia thành 5 pha chính: phân tích, thiết kế, chế tạo, kiểm thử và bảo trì • Phân tích: quá trình này nhằm mục đích hiểu được lĩnh vực thông tin, chức năng, hành vi, tính năng và giao diện của phần mềm sẽ phát triển. Quá trình này đòi hỏi phải tạo tư liệu và bàn thảo với khách hàng • Thiết kế: là quá trình gồm nhiều bước với 4 thuộc tính khác nhau của một chương trình: cấu trúc dữ liệu, kiến trúc phần mềm, biểu diễn giao diện và thuật toán. Quá trình này cần tư liệu hóa và là một phần quan trọng của cấu hình phần mềm • Chế tạo (lập trình): chuyển thiết kế thành chương trình máy tính bằng một ngôn ngữ lập trình nào đó • Kiểm thử: kiểm tra các chương trình và module logic bên trong và chức năng bên ngoài nhằm phát hiện ra lỗi và đảm bảo với đầu vào xác định thì cho kết quả mong muốn. • Bảo trì: đáp ứng những thay đổi, nâng cấp phần mềm đã phát triển do sự thay đổi của môi trường, nhu cầu. 1.4. Nền tảng thiết kế phần mềm trong sản xuất phần mềm 1.4.1. Khái niệm thiết kế phần mềm Thiết kế phần mềm được định nghĩa trong IEEE 610.12-96 bao gồm: Quá trình xác định kiến trúc, các thành phần, giao diện và các đặc tính kỹ thuật của hệ thống hoặc thành phần 1.4.2. Vai trò của công đoạn thiết kế phần mềm Thiết kế phần mềm là cơ sở cho giai đoạn tiếp theo là xây dựng phần mềm, nó đóng vai trò quan trọng trong phát triển phần mềm • Cho phép xem xét, so sánh các phương án kỹ thuật khác nhau trong thiết kế phần mềm. • Cho phép xác định phương án phù hợp nhất với các yêu cầu phần mềm. • Cho phép lập các kế hoạch chi tiết cho giai đoạn xây dựng phần mềm. Thiết kế Lập trình Kiểm thử Mô hình chức năng Mô hình tuyến tính Thiết kế CSDL Thiết kế thủ tục Phần mềm đã tích hợp Hình 3: Mô hình công đoạn thiết kế phần mềm Đối với một phần mềm có thiết kế khi phát triển thêm các chức năng cho phần mềm người ta luôn có một nền tảng định hướng rõ ràng mà sau này khi phát triển không gây ra những đổ vỡ cho phần mềm. Khi gặp những va chạm của thực tiễn một phần mềm không được thiết kế đầy đủ sẽ dễ dẫn đến những sai sót nghiêm trọng. Người ta thường mô tả một phần mềm có thiết kế và không có thiết kế bằng hình vẽ sau đây: Bảo trì Kiểm thử Cài đặt Thiết kế Kiểm thử Cài đặt Bảo trì Có thiết kế Không có thiết kế Hình 4: So sánh phần mềm có thiết kế và không có thiết kế 1.4.3. Một số phương pháp thiết kế phần mềm 1.4.3.1. Khái niệm module hoá Trong trường phái lập trình cấu trúc người ta dựa trên một ý tưởng gọi là module hoá mà bản chất của nó khá phù hợp với phương pháp phân tích của triết học tức là khi nghiên cứu một vấn đề nào đó chúng ta phân rã vấn đề đó thành những vấn đề nhỏ hơn, chi tiết hơn bao gồm từng bộ phận cấu thành nên vấn đề lớn. Trong tin học, vấn đề module hoá được sử dụng để khi chuyển từ vấn đề thực tế sang giải pháp phần mềm. Trong trường hợp này quá trình phân tích dừng lại ở các module độc lập và thông thường mỗi module tương ứng với một chương trình. Ta có thể biểu diễn quá trình module hoá thông qua sơ đồ cấu trúc hình cây sau đây. P P11 P12 P13 P21 P22 P31 P32 P1 P2 P3 Hình 5: Quá trình module hoá Nếu ta coi bài toán chính là module bậc 1 thì module này lại được phân chia thành các module bậc 2, bậc 3 . theo cấu trúc hình cây. 1.4.3.2. Phương pháp thiết kế từ trên xuống (Top Down Design) Ý tưởng tổng quát của phương pháp thiết kế từ đỉnh xuống là dựa vào quá trình module hoá một vấn đề thực tế. Khi giải quyết một vấn đề nào đó trước hết người ta đưa ra các phác thảo tổng quát. Sau đó trên cơ sở của phác thảo này sẽ tiếp tục chi tiết hoá thành các module ngày càng chi tiết và cụ thể hơn và dừng lại khi mỗi module tương ứng với một chương trình. 1.4.3.3. Phương pháp thiết kế từ dưới lên (Bottom Up Design) Ý tưởng của phương pháp này xét theo một góc độ nào đó là ngược lại với phương pháp thiết kế từ trên xuống và bao gồm các vấn đề sau: Trước hết tiến hành giải quyết các vấn đề cụ thể, sau đó trên cơ sở đánh giá mức độ tương tự về chức năng của các vấn đề này trong việc giải quyết bài toán người ta gộp chúng lại thành từng nhóm cùng chức năng từ dưới lên trên cho đến module chính. Sau đó sẽ thiết kế thêm một số chương trình làm phong phú hơn, đầy đủ hơn chức năng của các phân hệ và cuối cùng là thiết kế một chương trình làm nhiệm vụ tập hợp các module thành một hệ chương trình thống nhất, hoàn chỉnh. 1.4.4. Tiến trình thiết kế phần mềm Tiến trình thiết kế trong công nghệ phần mềm được xem xét từ nhiều góc độ khác nhau. Xuất phát từ quan điểm quản lý dự án thì qui trình thiết kế phần mềm theo hai bước: • Thiết kế kiến trúc phần mềm: mục đích xác định mô hình kiến trúc và các thành phần trong kiến trúc. • Thiết kế chi tiết phần mềm: Thiết kế chi tiết từng thành phần, xác định đầy đủ các thông tin tương ứng cho từng thành phần để có thể tiến hành xây dựng phần mềm. Xuất phát từ góc độ kĩ thuật thì qui trình thiết kế phần mềm bao gồm bốn loại: • Thiết kế kiến trúc. • Thiết kế dữ liệu. • Thiết kế thủ tục. • Thiết kế giao diện. Hai khía cạnh kĩ thuật và quản lý của qui trình thiết kế có mối liên quan mật thiết với nhau và được biểu diễn trong hình vẽ tổng quát dưới đây. Thiết kế kiến trúc Thiết kế dữ liệu Thiết kế thủ tục Thiết kế giao diện Thiết kế chi tiết Thiết kế sơ bộ Quản lý Kỹ thuật Hình 6: Quy trình thiết kế phần mềm 1.5. Các qui trình trong sản xuất phần mềm 1.5.1. Xây dựng và quản lý hợp đồng phần mềm 1.5.1.1. Mục đích Qui trình xây dựng và quản lý hợp đồng phần mềm có mục đích nghiên cứu, đề xuất giải pháp kĩ thuật tiến hành xây dựng hợp đồng đối với khách hàng; theo dõi tiến trình thực hiện hợp đồng; tổ chức thanh lý; thanh toán hợp đồng và lập hồ sơ tổng quát về qui trình hợp đồng phần mềm. 1.5.1.2. Dấu hiệu Qui trình xây dựng và quản lý hợp đồng phần mềm được đặc trưng bởi các dấu hiệu sau: - Xây dựng hợp đông phần mềm với khách hàng. - Theo dõi thực hiện hợp đồng phần mềm - Thanh toán, thanh lý hợp đồng phần mềm 1.5.1.3. Lưu đồ Mở đầu Xây dựng hợp đồng phần mềm Theo dõi hợp đồng phần mềm Thanh toán, thanh lý hợp đồng Kết thúc Báo cáo tổng kết qui trình Nghiên cứu đề xuất XD PM Lập giải pháp Hình 7: Lưu đồ quy trình xây dựng và quản lý hợp đồng 1.5.1.4. Các thông số Thông số Điều kiện bắt đầu Điều kiện kết thúc 1.Thông số chung (chức danh) Cán bộ kinh doanh Có đề xuất xây dựng hợp đồng PM 2. Đầu vào Đề xuất của khách hàng và duyệt của công ty PM 3. Sản phẩm Hợp đồng PM với khách hàng Giải pháp kĩ thuật 4. Đánh giá chất lượng Tỉ lệ các hạng mục của hợp đồng hoàn thành đúng hạn >=90% Chênh lệch thời gian dự kiến và thời gian thực tế là: +- 20% 5. Các qui trình liên quan Xác định yêu cầu PM 1.5.1.5. Phân đoạn các hoạt động STT Tên hoạt động Bắt đầu Hoàn thành 1 Lập giải pháp Có nhu cầu xây dựng PM 2 Xây dựng hợp đồng PM Kết thúc bước 1 HĐPM được duyệt 3 Theo dõi HĐPM Kết thúc bước 2 4 Thanh toán thanh lý HĐPM Kết thúc bước 3 Lãnh đạo công ty PM và khách hàng duyệt 5 Báo cáo qui trình Kết thúc bước 4 Công ty duyệt 1.5.2. Xác định yêu cầu phần mềm 1.5.2.1. Mục đích Sau khi đã có hợp đồng phần mềm với khách hàng; hợp đồng được chuyển sang để thực hiện yêu cầu thứ hai nhằm mục đích xác định cụ thể nhu cầu của khách hàng về phần mềm tương lai bao gồm: các chức năng của phần mềm, hiệu năng của phần mềm, các yêu cầu về thiết kế và giao diện, các yêu cầu đặc biệt khác. Yêu cầu đặt ra là phải lượng hoá và biểu diễn dưới dạng các mô hình. 1.5.2.2. Dấu hiệu Qui trình xác định yêu cầu phần mềm được đặc trưng bởi các dấu hiệu sau: • Phát hiện các yêu cầu phần mềm (Requirements elicitation) • Phân tích các yêu cầu phần mềm và thương lượng với khách hàng (Requirements analysis and negotiation) • Mô tả các yêu cầu phần mềm (Requirements specification) • Mô hình hóa hệ thống (System modeling) • Kiểm tra tính hợp lý các yêu cầu phần mềm (Requirements validation) • Quản trị các yêu cầu phần mềm (Requirements management) 1.5.2.3. Lưu đồ Lập kế hoạch xây dựng yêu cầu Mở đầu Xác định yêu cầu phần mềm Duyệt Phân tích nghiệp vụ Lập mô hình hệ thống Kết thúc Báo cáo qui trình Có Không Hình 8: Lưu đồ quy trình xác định yêu cầu phần mềm 1.5.2.4. Các thông số Thông số Mô tả Yêu cầu 1.Thông số chung (chức danh) Cán bộ xác định yêu cầu Theo tiêu chuẩn của công ty 2. Đầu vào Hợp đồng phần mềm 3. Sản phẩm Hồ sơ phần mềm nghiệp vụ chuyên sâu Mô hình hoạt động của hệ thống 4. Đánh giá chất lượng Các hồ sơ xác định yêu cầu được hoàn thành đúng hạn >=90% Chênh lệch thời gian dự kiến và thời gian thực tế là: +- 20% 5. Các qui trình liên quan Thiết kế Lập trình Test Triển khai 1.5.2.5. Phân đoạn các hoạt động STT Tên hoạt động Bắt đầu Hoàn thành 1 Lập kế hoạch xác định yêu cầu Kết thúc quá trình 1 2 Xác định yêu cầu người sử dụng Kết thúc bước 1 3 Phân tích nghiệp vụ Kết thúc bước 2 4 Mô tả hoạt động của hệ thống Kết thúc bước 3 5 Báo cáo qui trình Kết thúc bước 4 1.5.3. Qui trình thiết kế 1.5.3.1. Mục đích Sau quá trình xác định yêu cầu phần mềm, trên cơ sỏ hồ sơ của giai đọan phân tích người ta chuyển sang qui trình thiết kế nhằm mục đích xây dựng hồ sơ tổng thể các vấn đề thiết kế phần mềm từ thiết kế tổng quát đến thiết kế chi tiết 1.5.3.2. Các dấu hiệu Qui trình thiết kế trong công nghệ phần mềm được đặc trưng bởi dấu hiệu sau  Thiết kế kiến trúc phần mềm  Thiết kế kỹ thuật phần mềm  Thiết kế dữ liệu  Thiết kế thủ tục  Thiết kế chương trình  Thiết kế giao diện [...]... tâm tới nơi, thời điểm, và đối tượng chịu trách nhiệm xử lý Sơ đồ luồng dữ liệu đơn thuần mô tả hệ thống thông tin làm gì và để làm gì  Một số ký pháp cơ bản dùng cho sơ đồ luồng dữ liệu (DFD) Ngôn ngữ sơ đồ luồng dữ liệu DFD sử dụng bốn loại ký pháp cơ bản: thực thể, tiến trình, kho dữ liệu và dòng dữ liệu Tên người/ bộ phận phát/ nhận tin Nguồn hoặc đích Tên dòng dữ liệu Dòng dữ liệu Tên tiến trình... một cơ quan  Các HTTT có thể hoàn toàn thủ công hay dựa trên máy tính Ngoài máy tính điện tử, HTTT còn có con người, các phương tiện thông tin liên lạc, các quy tắc, thủ tục, phương pháp và mô hình toán học để xử lý dữ liệu, quản lý, phân phát và sử dụng thông tin Hầu hết các HTTT đều được gọi là hệ thống thông tin quản lý (HTTTQL) bởi vì nó phục vụ cho công tác quản lý 3.1.2 Khái niệm hệ quản trị cơ. .. liệu trong những kho dữ liệu, đó là nơi cất giữ dữ liệu một cách có tổ chức sao cho có thể tìm kiếm nhanh chón những dữ liệu cần thiết Nếu kho dữ liệu này được đặt trên các phương tiện nhớ của MTĐT và được bảo quản nhờ chương trình máy tính thì nó còn được gọi là ngân hàng dữ liệu (NHDL) hay hệ cơ sở dữ liệu  Giống với các hệ quản trị cơ sở dữ liệu Microsoft FoxPro, Oracle, hệ quản trị cơ sở dữ liệu... dụng phần mềm dễ mắc sai sót Do đó người ta yêu cầu khi xây dựng kịch bản không nên để ý đến những điểm mạnh của phần mềm Người ta nói rằng cán bộ Test không những làm công việc khoa học mà còn mang tính nghệ thuật Lập kế hoạch Test Mở đầu Kết thúc 1.5.4.7 Lưu đồ Lập kịch bản Test Duyệt? Không Có Test hệ thống Test nghiệm thu Ghi nhận những sai sót Báo cáo qui trình Test Hình 11: Lưu đồ quy trình Test... test toàn bộ phần mềm với các nội dung cơ bản: Test hệ thống, test theo tiêu chuẩn nghiệm thu nhằm đảm bảo có một phần mềm chất lượng cao Dấu hiệu 1.5.4.6 Quy trình Test trong công nghệ phần mềm được đặc trưng bởi các dấu hiệu sau đây:  Lập kịch bản test  Thực hiện quá trình Test hệ thống  Test nghiệp vụ Cần nhấn mạnh vai trò đặc biệt quan trọng của việc lập kịch bản Test Công việc chính của cán bộ... biệt quan trọng của việc lập kịch bản Test Công việc chính của cán bộ Test chương trình không phải là đi sửa lỗi của chương trình mà là xây dựng những kịch bản làm sao có thể phát hiện ngay những điểm yếu nhất của chương trình Do đó qui trình Test đòi hỏi không những am hiểu về tin học mà phải có sự hiểu biết thấu đáo về lĩnh vực ứng dụng của phần mềm Vì chỉ có nghiệp vụ chuyên sâu về lĩnh vực này chúng... viên dự án duyệt Quản trị viên dự án duyệt Quản trị viên dự án duyệt Qui trình lập trình Mục đích Trên cơ sở của hồ sơ thiết kế, bộ phận lập trình sẽ tiến hành chi tiết hoá các sơ đồ khối hay lưu đồ và lựa chọn một ngôn ngữ lập trình nào đó phù hợp để biến bản vẽ thiết kế thành sản phẩm phần mềm Nhưng bản thân công đoạn lập trình phải trung thành với thiết kế kiến trúc của phần mềm; không được làm thay... Quản trị viên dự án duyệt Quản trị viên dự án duyệt 2 Công cụ nghiên cứu đề tài 2.1 Công cụ mô hình hóa 2.1.1 Sơ đồ luồng thông tin (IFD) Sơ đồ luồng thông tin được dùng để mô tả hệ thống thông tin theo cách thức động Nghĩa là mô tả sự di chuyển của dữ liệu, việc xử lý, việc lưu trữ trong thế giới vật lý bằng các sơ đồ Các ký pháp của sơ đồ luồng thông tin:  Xử lý Thủ công Bán tự động Tự động  Kho... Phần mềm Hợp đồng Phần mềm đã Test qua Biên bản ghi nhận quá trình Test Các sản phẩn PM được Test đúng hạn >=90% Thời gian dự kiến và thời gian thực tế để Test là: +- 20% Hợp đồng PM Lập trình Yêu cầu Theo tiêu chuẩn của công ty Quản trị viên dự án duyệt Quản trị viên dự án duyệt Phân đoạn các hoạt động 1.5.4.9 STT 1 2 Tên hoạt động Lập kế hoạch Test Lập kịch bản Bắt đầu Bắt đầu qui trình 5 Kết thúc bước... phải làm • Nhóm vào thành các khối công việc • Tìm tên phù hợp cho các nhóm • Phân các công việc vào các nhóm • Vẽ ra dưới dạng sơ đồ 3 Lý thuyết về hệ quản trị cơ sở dữ liệu Microsoft Access và ngôn ngữ lập trình Visual Basic 3.1 Hệ quản trị cơ sở dữ liệu Micxrosoft Access 3.1.1 Khái niệm hệ thống thông tin  Hệ thống thông tin (HTTT) là một tập hợp các yếu tố có liên quan với nhau cùng làm nhiệm vụ . NHỮNG VẤN ĐỀ PHƯƠNG PHÁP LUẬN CƠ BẢN 1. Một số khái niệm cơ bản về thiết kế và xây dựng phần mềm 1.1 Khái. khá phù hợp với phương pháp phân tích của triết học tức là khi nghiên cứu một vấn đề nào đó chúng ta phân rã vấn đề đó thành những vấn đề nhỏ hơn, chi