Phần mềm quản lý bán hàng cho phép nhân viên quản lý bán hàng xác định được năng xuất của lực lượng bán hàng, triển vọng kinh doanh tại các điểm bán hàng và mức độ thành công của các sản phẩm theo các tiêu thức khác nhau: theo khách hàng, theo nhóm khách hàng, theo loại hàng…
Nó cho phép nhà quản lý tìm ra các điểm kinh doanh yếu kém hay các sản phẩm lỗi bị trả lại, xác định các xu thế kinh doanh, xác dịnh lượng tồn kho để thực hiện quá trình lên kế hoạch, kiểm tra và tô chức các công việc khác một cách dễ dàng và nhanh chóng. Phần mềm này có thể truy cập dữ liệu từ các cơ sở dữ liệu được cập nhật bởi các nhân viên bán hàng, bằng cách sử dụng phần mềm trợ giúp bán hàng.
Chương 2. Cơ sở phương pháp luận của phần mềm ứng dụng 2.1 Thông tin quản lý và hệ thống thông tin quản lý:
2.1.1 Hệ thống trong phân tích thiết kế phần mềm:
Hệ thống là một tổ hợp phần cứng, phần mềm cung cấp giải pháp cho vấn đề cần giải quyết. Ngày nay trong khi hệ thống quá phức tạp mà tri thức lại quá chuyên ngành cho nên một người không thể biết một khía cạnh tác nghiệp. Một người khó có thể hiểu được đồng thời mọi vấn đề của hệ thống. Từ thiết kế giải pháp, viết mã chương trình, triển khai trên nền phần cứng đến đảm bảo chắc chắn mọi thành phần phần cứng làm việc tốt với nhau. Tiến trình phần mềm phức tạp phải được nhiều người thực hiện. Trước hết là khách hàng, đó là người đưa ra vấn đề cần giải quyết. Phân tích viên làm tài liệu vấn đề của khách hàng và chuyển nó tới người phát triển, đó là những cái lập trình viên xây dựng phần mềm để giải quyết, kiểm tra và triển khai nó trên phần cứng. Phát triển phần mềm có thể được thực hiện bằng nhiều con đường khách nhau. Các dự án có thể tuân thủ một trong các tiến trình phát triển, bao gồm từ tiến trình thác nước tới tiến trình lặp và tăng dần. Mỗi loại có ưu nhược điểm riêng.
2.1.2 Thông tin trong quản lý:
Quản lý được hiểu là tập hợp các quá trình biến đổi thông tin thành hành động, một việc tương đương với quá trình ra quyết định.
Hình vẽ dưới đây là sự thể hiện một tổ chức do R.N Anthony đưa ra, Anthony trình bày tổ chức như là một thực thể cấu thành từ ba mức quản lý:
Sơ đồ 2.1 Tháp quản lý trong tổ chức.
Các quyết định của tổ chức chia thành bà loại: Quyết định chiến lược, quyết định chiến thuật và quyết định tác nghiệp.
Quyết định chiến lược là những quyết định xác định mục tiêu và những quyết định xây dựng nguồn lực cho tổ chức.
Quyết định chiến thuật là những quyết định cụ thể hóa mục tiêu thành nhiệm vụ, những quyết định kiểm soát và khai thác tối ưu nguồn lực.
Quyết định tác nghiệp là những quyết định nhằm thực thi nhiệm vụ.
2.1.3 Tính chất của thông tin:
Tính tương đối. Tính định hướng Tính thời điểm. Tính cục bộ.
2.1.4 Khái niệm về hệ thống thông tin:Định nghĩa về hệ thống thông tin: Đị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
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 • Bảo trì hoàn thiện
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