Định nghĩa về hệ thống thông tin:
Hệ thống thông tin là một tập hợp những con người, các thiết bị phần cứng, phần mềm, dữ liệu…Thực hiện nhiệm vụ thu thập, lưu trữ, xử lý và phân phối thông tin trong một tập các ràng buộc được gọi là môi trường.
Hệ thống thông tin của mỗi tổ chức là khác nhau nhưng đều tuân thủ theo nguyên tắc sau: nó được thể hiện bởi con người, các thủ tục, dữ liệu và thiết bị tin học. Đầu vào (inputs) của hệ thống thông tin được lấy từ nguồn và được xử lý bởi hệ thống sử dụng nó cùng với các dữ liệu đã được lưu trữ từ trước. Kết quả xử lý được chuyển đến các đính hoặc được cập nhật và các kho dữ liệu.
Sơ đồ 2.2 Mô hình hệ thống thông tin 2.2 Phân loại hệ thống thông tin trong tổ chức doanh nghiệp: 2.2.1 Phân loại:
Các thông tin trong một tổ chức được phân chia theo cấp quản lý và trong
mỗi cấp quản lý chúng lại được chia theo nghiệp vụ mà chúng phục vụ. Nguồn Thu thập Xử lý và lưu trữ Phân phát Đích Kho dữ liệu
Tài chính chiến lược Marketing chiến lược Nhân lực chiến lược Kinh doanh và sản xuất chiến lược Hệ thống thông tin văn phòng Tài chính chiến thuật Marketing chiến thuật Nhân lực chiến thuật Kinh doanh và sản xuất chiến thuật Tài chính tác nghiệp Marketing tác nghiệp Nhân lực tác nghiệp Kinh doanh và sản xuất tác nghiệp
2.2.2 Tầm quan trọng của hệ thống thông tin hoạt động tốt:
Quản lý có hiệu quả của một tổ chức dựa phần lớn và chất lượng thông tin
do các hệ thống thông tin chính thức sản sinh ra. Sự hoạt động kém của một hệ thống thông tin sẽ là nguồn gốc gây ra những hậu quả nghiêm trọng.
Hoạt động tốt hay xấu của một hệ thống thông tin được đánh giá thông qua chất lượng của thông tin mà nó cung cấp. Tiêu chuẩn chất lượng của thông tin như sau:
• Độ tin cậy: thể hiện các mặt về độ xác thực và độ chính xác.
• Tính đầy đủ: thể hiện sự bao quát các vấn đề đáp ứng các yêu cầu của nhà quản lý.
• Tính thích hợp và dễ hiểu.
• Tính được bảo vệ: thông tin là một nguồn lực quý báu của tổ chức do vậy nó phải được bảo vệ, những người có quyền mới được tiếp nhận.
• Tính kịp thời: thông tin nhanh nhạy, gửi tới người sử dụng vào lúc cần thiết.
2.3 Một số công cụ mô hình hóa:
2.3.1 Sơ đồ chức năng kinh doanh (BFD):
Sơ đồ chức năng kinh doanh mô tả mối quan hệ phân cấp chức năng các
thực thể từ cao xuống thấp. Trong đó một thực thể có thể có nhiều thực thể con và thực thể dưới là con của thực thể đứng trên. Sử dụng trong giai đoạn phân tích hệ thống thông tin, đồng thời là căn cứ cho giai đoạn thiết kế thiết kế các chức năng tương ứng.
2.3.2 Sơ đồ luồng dữ liệu (DFD):
Sơ đồ luồng dữ liệu dùng để mô tả hệ thống thông tin. Trên sơ đồ chỉ bao gồm các luồng dữ liệu, các xử lý, các lưu trữ dữ liệu,nguồn và đích nhưng không quan tâm đến thời điểm, nơi và đối tượng chịu trách nhiệm xử lý. Sơ đồ luồng dữ liệu chỉ mô tả hệ thống thông tin làm gì và để làm gì.
Một số ký pháp dùng cho sơ đồ luồng dữ liệu: - Thực thể - Dòng dữ liệu Tên dòng dữ liệu - Kho dữ liệu Tên tệp dữ liệu - Tiến trình xử lý
Trong tiến trình xử lý ít nhất phải có một đầu vào và một đầu ra. Tên người/bộ phận
phát/nhận tin
Tên tiến trình xử lý
2.4 Công nghệ phần mềm và một số mô hình trong phát triển phần mềm:2.4.1 Khái niệm công nghệ phần mềm (CNPN): 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: