2.4.1 Khái niệm công nghệ phần mềm (CNPN):
Công nghệ phần mềm:
CNPN là một tổ hợp các công cụ, phương pháp, thủ tục làm cho người quản trị viên dự án nắm được xu thế tổng quát phát triển phần mềm và giúp cho kỹ sư lập trình có một nền tảng để triển khai các định hướng của phần mềm.
Sơ đồ 2.3 Cấu trúc công nghệ phần mềm
Quá trình phát triển của một dự án phần mềm đều trải qua ba giai đoạn.
Giai đoạn một:
Trả lời cho cầu hỏi “Cái gì ?”. Tức là người sản xuất phần mềm phải xác định cụ thể và chi tiết sản phẩm phần mềm mà mình cần tạo ra. Đây là công đoạn cực kỳ quan trọng trong sản xuất phần mềm ở quy mô công nghiệp, vì chỉ có xác định rõ ràng phạm vi của sản phẩm và các ràng buộc liên quan ta mới có thể tiến hành được kết quả của các công đoạn sau.
Phải giải quyết ba vấn đề mấu chốt là tiến hành phân tích hệ thống một cách toàn diện theo quan điểm một phần mềm là một thành phần của hệ thống quản
Công nghệ phần mềm Thành phần Công cụ Phương pháp Thủ tục Chức năng Quản trị viên dự án Kỹ sư phần mềm
lý do đó nó phải được đặt trong tổng thể hệ thống đó và xem xét mối quan hệ ràng buộc các yếu tố quản lý khác.
Giai đoạn hai:
Trả lời cho câu hỏi “Thế nào ?”. Tức là định hướng phần mềm sẽ phát triển thế nào trong đó có ba công việc cơ bản cần làm: thiết kế, mã hóa, kiểm thử. Mã hóa trong công nghệ phần mềm là viết mã chương trình: biên dịch chương trình từ ngôn ngữ thiết kế sang một ngôn ngữ mà máy tính có thể hiểu.
Giai đoạn ba:
Trả lời cho cầu hỏi “Thay đổi ra sao ?”. Có ba loại hình bảo trì là: bảo trì sửa đổi, bảo trì thích nghi và bảo trì hoàn thiện hay bảo trì nâng cao. Bảo trì sửa đổi là sửa lỗi phần mềm, thông thường là lỗi chi tiết, đơn giản, không phải là lỗi hệ thống. Bảo trì thích nghi là làm cho phần mềm hoàn thiện trong môi trường của người sử dụng. Bảo trì hoàn thiện: làm cho phần mềm có thể hoạt động tốt trong các môi trường khác nhau.
Sơ đồ 2.4 Các giai đoạn của quy trình phát triển phần mềm
Xác định
Phát triển
Bảo trì
Giai đoạn một
Giai đoạn hai
Xác định Phát triển Bảo trì
Khái niệm phần mềm :
Theo Roger Pressman phần mềm là một tập hợp gồm ba yếu tố là: các chương trình máy tính, cấu trúc dữ liệu và hệ thống tài liệu hướng dẫn.
Các giai đoạn phát triển của phần mềm: Thời kỳ 1950-1960 1960-1970 1970-1990 1990-Nay Chậm. Xử lý theo lô. Phần mềm đơn chiếc. Sản xuất cho nhóm người dùng. Chế độ thời gian thực.
Thương mại hóa.
Hệ thống phân tán.
Tính tới hiệu quả thương mại. Phần mềm thông minh. Hệ thống để bàn. Lập trình hướng đối tượng. Xử lý song song. 2.4.2 Vòng đời phát triển phần mềm:
Trong công nghiệp phần mềm người ta đặc biệt quan tâm tới vấn đề là vòng
đời phát triển phần mềm. Vòng đời phát triển của một phần mềm được hiểu là quy trình từ khi phần mềm ra đời cho đến khi đưa vào sử dụng và quá trình nâng cấp bảo trì.
Mục đích của việc nghiên cứu vòng đời phát triển của phần mềm là phân ra các giai đoạn trên cơ sở đó tìm các giải pháp và công cụ thích hợp để tác động vào mỗi giai đoạn.
• Thiết kế
• Mã hóa
• Kiểm thử
• Phân tích hệ thống
• Kế hoạch
• Phân tích yêu cầu
• Bảo trì sửa đổi
• Bảo trì thích nghi
Sơ đồ 2.5 Mô hình thác nước 2.4.3 Mô hình thác nước:
Công đoạn đầu tiên là công nghệ hệ thống: nó bao trùm lên toàn bộ quy trình tiếp theo trong công nghệ phần mềm, vì phần mềm là một thành phần của hệ thống quản lý, do đó nó phải được xem xét trong mối liên hệ tổng thể về kinh tế - kỹ thuật - tổ chức của toàn bộ guồng máy quản lý. Công đoạn tiếp theo là phân tích: với mục đích xác định rõ ràng và cụ thể các yêu cầu của phần mềm, phần thiết kế trong Công Nghệ Phần Mềm hướng tới các vấn đề sau:
+Thiết kế kiến trúc hệ thống. +Thiết kế kỹ thuật.
Phần thiết kế hệ thống là quan trọng nhất vì nó cho ta cái nhìn tổng thể về phần mềm cần xây dựng. Còn thiết kế kỹ thuật đi vào các vấn đề cụ thể bao gồm: thiết kế dữ liệu, thiết kế thủ tục, thiết kế giải thuật, thiết kế giao diện, thiết kế công cụ cài đặt.
Công nghệ hệ thống Phân tích Thiết kế Mã hóa Kiểm thử Bảo trì
Người ta dùng mô hình thác nước để biểu diễn vòng đời phát triển của phần mềm với hai ý nghĩa: khẳng định đây là các giai đoạn của một quy trình thống nhất và không tách rời và có mối quan hệ mật thiết với nhau.
Trong mô hình này các công đoạn càng ở phía dưới thì càng phải chịu sự tác động của các giai đoạn phía trên, chỉ trừ có giai đoạn công nghệ hệ thống là không chịu tác động của giai đoạn nào.
Để xây dựng được một hệ thống phần mềm phải mô tả được vấn đề và yêu cầu của khách hàng bằng trả lời các câu hỏi như: Vấn đề của hệ thống là gì?. Hệ thống phải làm gì?. Phải phân tích của tiến trình tập trung vào việc điều tra vấn đề thay cho việc tìm ra giải pháp. Để có tài liệu phân tích đầy đủ và đúng đắn thì phải phân tích lĩnh vực vấn đề. Lĩnh vực vấn đề là khu vực tác nghiệp của con người trong đó phần được xây dựng.
Những người tham gia vào xây dựng hệ thống phần mềm như: khách hàng, phân tích viên, lập trình viên…Theo phương pháp thác nước rất ít khi làm việc cùng với nhau để chia sẻ các hiểu biết sâu sắc về vấn đề đang giải quyết. Do vậy sẽ mất nhiều thời gian để xây dựng được hệ thống phần mềm.
Mô hinh thác nước còn được biểu diễn dưới dạng chữ V trong đó quy trình kiểm tra được thực hiện đồng thời với các quy trình phát triển khác, ví dụ kiểm tra chức năng được thực hiện trong quá trình phân tích, kiểm tra tích hợp được thực hiện trong quá trình thiết kế, kiểm tra module trong quy trình lập trình.
Sơ đồ 2.6 Mô hình thác nước 2.4.4 Mô hình lặp và tăng dần:
Mô hình thác nước không cho đi ngược lại chuỗi trình tự phát triển phần
mềm, theo mô hình này thì phải xác định toàn bộ yêu cầu, nó được thực hiện thông qua bàn bạc với người sử dụng hệ thống và khảo sát các chi tiết của tiến trình tác nghiệp. Thực tế khi kết thúc công việc may mắn lắm chỉ 80% nhu cầu của hệ thống là được thu thập trong quy trình phân tích do khi đặt hàng bản thân khách hàng chỉ mới liệt kê ra những mong muốn và nguyện vọng của mình về phần mềm mà chưa hình dung được một cách cụ thể những khả năng mà phần mềm sẽ đạt được đồng thời kỹ sư phần mềm ngay từ đầu nhận đơn đặt hàng cũng không thể hình dung hết kiến trúc tổng quát của phần mềm mà mình xây dựng. Tiếp theo là quy trình thiết kế, nơi kiến trúc hệ thống sẽ được xác định, quy trình này tập trung vào những nhiệm vụ như đặt chương trình ở đâu, cần phần cứng nào…Trong khi thực hiện công việc này. Có thể
Phân tích Thiết kế Mã hóa Chương trình ứng dụng Kiểm tra chức năng Kiểm tra tích hợp Kiểm tra module
tìm ra một số nhiệm vụ mới của hệ thống. Do đó xuất hiện nhu cầu đi ngược lại người sử dụng để trao đổi bàn bạc về nó, có nghĩa là phải trở lại quy trình phân tích. Sau khi lặp lại vài lần như vậy mới chuyển đến quy trình lập trình hệ thống. Khi mã hóa chương trình, phát hiện ra một vài quyết định khi thiết kế là không thể cài đặt. Nên phải quay trở lại quy trình phân tích để xem xét lại yêu cầu. Sau quy trình lập trình, quy trình kiểm thử bắt đầu. Trong khi kiểm thử và nhận thấy một vài yêu cầu chưa đủ chi tiết, giải thích nhầm lẫn có thể xảy ra. Vậy phải trở lại quy trình phân tích để xem xét lại yêu cầu. Sau một vài lần lặp lại như vậy có được hệ thống hoàn chỉnh giao cho khách hàng. Vấn đề luật pháp, quy trình kinh doanh có thể thay đổi theo thời gian khi xây dựng hệ thống, người dùng có thể phàn nàn về các vấn đề này, sản phẩm làm ra không đúng như họ mong đợi. Nguyên nhân có thể là sự thay đổi của pháp luật, môi trường kinh doanh, khách hàng không truyền đạt đúng ý khách hàng yêu cầu, đội ngũ dự án không tuân thủ tiến trình…Đội ngũ phát triển thường lập ra các biểu đồ và vô số tài liệu, văn bản, nhưng người dùng không phải lúc nào cũng hiểu cái mà đội ngũ phát triển cung cấp cho khách hàng. Giải pháp nào để tránh các vấn đề này? Câu trả lời là mô hình hóa trực quan có thể giúp khách hàng.
Phát triển phần mềm là tiến trình phức tạp. Nếu bỏ qua khả năng quay trở lại của các bước thực hiện trước đó thì thiết kế hệ thống có thể sai lầm và thiếu sót nhu cầu. Để có thể đi ngược lại các bước phát triển hệ thống phần mềm sẽ có phương pháp mới, phương pháp phát triển lặp. Phát triển lặp là làm di làm lại việc gì đó. Trong phương pháp này ta sẽ đi qua các bước phân tích, thiết kế, phát triển, kiểm thử và triển khai phần mềm theo từng bước nhỏ nhiều lần. Bởi khó có thể thu thập được đầy đủ mọi yêu cầu vào công đoạn đầu tiên của dự án. Các vấn đề mới nảy sinh, vậy phải lập kế hoạch lặp trong dự án. Theo quan niệm này thì dự án được coi là các thác nước nhỏ, mỗi thác
nước được thiết kế đủ lớn để sao cho có thể hoàn thiện từng bộ phận quan trọng của dự án và đủ nhỏ để tối thiểu việc đi trở lại.
Sơ đồ 2.7 Mô hình lặp tăng dần
Theo mô hình lặp và tăng dần thì mỗi chu kỳ lặp là một vòng đời thác nước nhỏ. Vòng lặp sau được hình thành trên cơ sở tiến hóa của vòng lặp trước đó. Như vậy các quy trình truyền thống được lặp đi lặp lại và tăng dần. Trong phương pháp này, phân tích viên, người thiết kế, người lập trình…Hợp tác làm việc với nhau để hiểu sâu sắc hệ thóng, chia sẻ các ý tưởng mới dẫn đến xây dựng được một hệ thống mạnh, phức tạp hơn.
2.4.5 Cấp bậc kiến trúc phần mềm:
Cấp bậc kiến trúc của phần mềm được hiểu là thứ bậc trình tự các khối và
mối liên kết giữa chúng với nhau. Như vậy đứng trước một vấn đề thực tiễn người kỹ sư phần mềm có thể đưa ra nhiều giải pháp khác nhau để giải quyết
Công nghệ hệ thống Phân tích Thiết kế Mã hóa Kiểm thử Bảo trì
vấn đề đó, cấp bậc kiến trúc phần mềm hoàn toàn phụ thuộc vào trình độ chuyên môn của mỗi người.
Yêu cầu của mỗi kiến trúc phần mềm là phải đạt được hai vấn đề:
• Đảm bảo tính chặt chẽ trong kiến trúc để không xảy ra những lỗ hổng phần mềm.
• Kiến trúc phải đảm bảo không quá phức tạp để khi dịch thành chương trình thì quy mô của chương trình không quá lớn khi thực hiện mỗi chức năng.
Mô hình từ bài toán thực tế sang bài toán logic (Problem - Solution).
Sơ đồ 2.8 Mô hình chuyển đổi từ vấn đề thành các giải pháp
Mô hình này cho ta thấy với một vấn đề thực tế nhưng qua bàn tay chế tác của kỹ sư phần mềm có thể trở nên rất nhiều kiến trúc phần mềm khác nhau. Tiêu chuẩn duy nhất để lựa chọn một kiêu kiến trúc nào đó là không quá phức
Solution 1 S1 S2 S3 S5 S7 S4 S6 Problem Solution 2 S1 S2 S3 S5 S4 S6
tạp nhưng vẫn đảm bảo tính năng hoạt động của phần mềm. Đây chính là quá trình cấu trúc hóa các vấn đề phi cấu trúc.
2.5 Giới thiệu một số công cụ phát triển:
2.5.1 Hệ quản trị cơ sở dữ liệu Microsoft Access 2003:
Microsoft Access là một hệ quản trị cơ sở dữ liệu quan hệ (RDMS – Relational Database Management System) phù hợp với các bài toán xử lý vừa và nhỏ, số lượng người dùng ít. Khi sử dụng Microsoft Access người dùng có thể tìm kiếm, khai thác, thao tác với dữ liệu và truy xuất thông tin nhanh chóng và dễ dàng, lập trình rất thuận tiên với Visual Basic 6.0. Chi phí triển khai rẻ vì không cần những máy server lớn.
Microsoft Access là một thành phần của phần mềm Microsoft Office Professional, vì thế mà những đối tượng thuộc giao diện như thực đơn, thanh công cụ và hộp thoại tương tự như các ứng dụng khác của office mà phần lớn cán bộ văn phòng đã quen dùng. Việc trao đổi dữ liệu giữa Access và các ứng dụng khác trong môi trường Windows cũng rất thuận tiện.
Access có rất nhiều chức năng để đáp ứng những nhu cầu khác nhau về Cơ Sở Dữ Liệu Có thể dùng Access để phát triển sáu kiểu ứng dụng phổ biến nhất: ứng dụng cá nhân, ứng dụng cho doanh nghiệp nhỏ, ứng dụng cho nội bộ từng phòng ban, ứng dụng cho toàn công ty, ứng dụng ở tuyến trước cho các Cơ Sở Dữ Liệu theo mô hình khách chủ trên một phạm vi toàn doanh nghiệp và ứng dụng trên mạng nội bộ của một cơ quan.
Các thành phần của một cơ sở dữ liệu Access:
Table (Bảng): các bảng lưu dữ liệu được định dạng theo cột và dòng, tương
tự như việc ứng dụng bảng tính. Có thể tạo và mở nhiều bảng (được giới hạn bởi bộ nhớ của máy tính).
Query (Truy vấn): Mỗi truy vấn là một câu hỏi đơn giản từ cơ sở dữ liệu
không muốn hiển thị toàn bộ dữ liệu trong cơ sở dữ liệu, bằng việc dùng các truy vấn có thể xác định xem những bản ghi nào và những trường nào từ các bảng dữ liệu đã có sẽ được hiển thị.
Form (Mẫu biểu): Các form được sử dụng để truy nhập dữ liệu và cập nhật
các dữ liệu hiện thời. Các form sẽ hiển thị dữ liệu thường là một bản ghi nhiều hơn là dạng cột và dòng. Các form có thể đại diện cho các trường trong bảng theo bất kỳ một trật tự nào và làm cho việc nhập dữ liệu nhanh hơn và đơn giản hơn.
Report (Báo cáo): Các báo cáo là tổng hợp các bản in ra của Cơ Sở Dữ Liệu
và được tạo ra trong bất kỳ định dạng nào mà người sử dụng muốn. Các báo cáo có thể được tạo ra từ bất kỳ bảng hoặc bản mẫu câu hỏi nào mà người dùng đã thiết kế trước đó.
Macro: Macro có thể tự động hóa các thao tác trong Access. Sử dụng macro
người dùng có thể tạo Cơ Sở Dữ Liệu với đầy đủ chức năng mà không cần phải viết bất kỳ mã code nào.
Module: Module gồm mã Visual basic, được viết cho người sử dụng hoặc
do người sử dụng viết ra để thực hiện các thao tác mà các macro của Access không thể hỗ trợ được.
2.5.2 Microsoft Visual Basic 6.0:
Visual Basic là ngôn ngữ lập trình để phát triển các phần mềm ứng quan, nghĩa là khi thiết kế chương trình người lập trình có thể nhìn thấy ngay kết quả từng thao tác và tác dụng của chúng. Visual Basic gắn liền với khái niệm lập trình trực giao diện khi chương trình thực hiện. Visual Basic còn cho phép thực hiện chỉnh sửa nhanh chóng màu sắc, kích thước, hình dáng của các đối tượng.
Thuật ngữ “Visual” dùng để nói đến các phương thức dùng để tạo giao diện đồ họa người sử dụng. Thay vì viết những dòng mã lệnh để mô tả sự xuất
hiện và vị trí của những thành phần giao diện người sử dụng chỉ cần thêm