CHƯƠNG 1: TỔNG QUAN ĐỀ TÀI 1. Lý do chọn đề tài. Ngày nay, đi đôi với cơ chế phát triển xã hội theo hướng công nghiệp hóa, hiện đại hóa chính là sự thâm nhập không ngừng nghỉ của công nghệ thông tin trong mọi lĩnh vực đời sống. Trong đó có thể kể đến là sự đóng góp rất lớn của công nghệ thông tin trong quản lý bán hàng .Nếu trước đây việc quản lý bán hàng rất khó khăn, mất thời gian, thiếu chính xác và tốn nhiều công sức qua việc ghi chép trong các tài liệu, sổ sách,.
thì hiện nay, mọi thứ đã trở nên dễ dàng hóa nhờ sự trợ giúp của các phần mềm quản lý và bán hàng. Tuy nhiên, bên cạnh chưa có một phần mềm quản lý và bán hàng một cách hiệu quả. Nắm bắt được yêu cầu đó của thị trường, nhóm chúng em quyết định chọn đề tài “Xây dựng phần mềm quản lý bán hàng” để triển khai nhằm giải quyết vấn đề nan giải đó. Đồng thời có thể học hỏi thêm nhiều kiến thức, kỹ năng mới trong quá xây dựng phần mềm và báo cáo môn công nghệ phần mềm 1.
Mục tiêu đề tài. Vì đây là một dự án nhỏ nên nhóm chúng em sẽ ứng dụng “Mô hình thác nước” (Waterfall Model) để xây dựng phần mềm. Nhóm đã đặt ra các mục tiêu như sau: Thứ nhất, hiểu rõ hơn về quy trình xây dựng phần mềm một cách chuyên nghiệp và bài bản thông qua mô hình Waterfall Model. Thứ hai, đề tài còn giúp các thành viên trong nhóm tự tăng thêm khả năng nghiên cứu về open source odoo quản lý bán hàng để quản lý dự án và xây dựng phần mềm.
Mục tiêu cuối cùng và không kém phần quan trọng đó là sau đồ án này, mỗi người chúng em đều sẽ nâng cao kinh nghiệm về cách tổ chức và làm việc nhóm (teamwork). Phạm vi đề tài. Phần mềm sử dụng hệ quản trị cơ sở dữ liệu của odoo 1. Phần mềm tập trung vào việc quản lý và bán hàng, không tập trung nhiều vào việc quản lý nhập xuất kho hay quản lý tại quầy.
Phần mềm hướng đến một giao diện đơn giản, thân thiện với người dùng và rất dễ sử dụng. Phần mềm hoạt động trên mạng cục bộ (LAN) hoặc Mạng diện rộng (WAN) 1. Ý nghĩa thực tiễn Từ tên đề tài “Xây dựng phần mềm quản lý bán hàng” đã khái quát lên được phần chính công cuộc xây dựng phần mềm đúng nhu cầu theo quy trình xác định. Ý nghĩa đối với người sử dụng hệ thống.
Phần mềm được thiết kế dựa trên tiêu chí lựa chọn nhu cầu theo phương pháp MOSCOW, nhằm ưu tiên nhất vào những chức năng cơ bản được hoàn thiện chính xác nhất và nâng cấp dần vào những chức năng đi kèm. Ý nghĩa với cá nhân sinh viên. Đề tài này vừa là bản báo cáo học phần và cũng vừa là một dịp cụ thể để cho các thành viên trong nhóm có thể tìm hiểu thêm những kiến thức mới bao gồm cả kiến thức chuyên môn và kiến thức văn hóa xã hội, củng cố lại kiến thức cũ và ứng dụng vào thực tế. Bên cạnh, khi thực hiện đề tài thì nhóm cũng đã bổ sung được vào từng cá nhân cách thức để làm việc nhóm trong quá trình xây dựng sản phẩm.
Tổng quan về mô hình thác nước (Waterfall model) và phương pháp thực hiện đề tài. Mô hình thác nước (Waterfall model) hay còn được gọi là mô hình tuần tự tuyến tính được giới thiệu vào năm 1970. Nó được gọi là mô hình tuần tự tuyến tính là vì các pha của mô hình thông thường chỉ được thực hiện một lần và không có sự quay lại giữa các pha và phải đi theo trình tự từ trên xuống dưới trông như thác nước đổ. Pha tiếp theo chỉ được bắt đầu khi pha trước đó đã được hoàn thành.
Trước đây mô hình thác nước được sử dụng rất phổ biến nhưng ngày nay nó rất ít khi được sử dụng bởi tính kém linh hoạt giữa các giai đoạn trong quá trình phát triển phần mềm và đòi hỏi phải có sự chặt chẽ, rõ ràng về yêu cầu ngay từ giai đoạn đầu tiên của quá trình phát triển. Mặc dù độ phổ biến của mô hình thác nước không còn được rộng rãi như trước nhưng nó vẫn rất quan trọng vì tất cả các mô hình phát triển phần mềm khác đều dựa trên mô hình thác nước. Phân tích các giai đoạn. Mô hình thác nước được chia thành 5 giai đoạn: 1.
Phân tích yêu cầu (Requirements definition) 2. Thiết kế hệ thống và phần mềm (System and software design) 3. Hiện thực và kiểm tra modules (Implementation and unit testing) 4. Tích hợp và kiểm tra hệ thống (Integration and system testing) 5.
Chuyển giao và bảo trì (Operation and maintenance) Hình ảnh minh họa mô hình thác nước: 1. Chi tiết các giai đoạn. Phân tích yêu cầu (Requirements definition). Đây là giai đoạn quan trọng nhất trong 5 giai đoạn bởi vì đây cũng chính là nguyên nhân gây ra sự thất bại nhiều nhất.
Người dùng thường chỉ đưa ra những ý tưởng, nhiều khi rất mơ hồ về phần mềm mà họ mong muốn xây dựng. Mục đích của giai đoạn này là để hiểu các yêu cầu chính xác của khách hàng. Vậy nên các lập trình viên sẽ phải thu thập tất cả các yêu cầu cần thiết từ khách hàng, sau đó sẽ phân tích để hiểu đúng những yêu cầu về phần mềm. Yêu cầu của phần mềm là tất cả các yêu cầu về phần mềm do người dùng nêu ra 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, giao diện của phần mềm và một số các yêu cầu khác.
Bên cạnh, sự thay đổi yêu cầu của phần mềm trong quá trình làm đồ án là một điều tất yếu, hiển nhiên hoàn toàn có thể xảy ra khiến cho việc phân tích yêu cầu trở thành giai đoạn khó nhất. Thiết kế hệ thống và phần mềm (System and software design). Giai đoạn này nhằm mục đích chuyển đổi các yêu cầu thu thập được từ khách hàng thành các bản vẽ thiết kế chi tiết cũng như kiến trúc phần mềm tổng thể của hệ thống. Nếu người thực hiện đồ án chỉ làm bản vẽ cho có hay làm bản vẽ 1 cách sơ xài, cho có hình thức thì sẽ là vô nghĩa, phần mềm không thể phát triễn được.
Mọi bản vẽ thiết kế đều có được mục đích cụ thể (để đảm bảo, nâng cấp, bảo trì,…). Giai đoạn phân tích thiết kế có 3 mức, đòi hỏi phải am hiểu về lập trình hướng đối tượng, cơ sở dữ liệu. Dựa vào thực tế, người dùng là chính, bài bản chỉ mang tính kĩ thuật cá nhân. Muốn tích hợp được hay không phải nắm được bản thiết kế.
Hiện thực và kiểm tra modules (Implementation and unit testing). Tại đây, thiết kế được thực hiện và xem xét có giống phân tích và thiết kế không. Từ đó, các lập trình viên sẽ tạo ra chương trình bằng ngôn ngữ lập trình. Các đoạn code sẽ được kiểm tra kỹ lưỡng và sửa đổi nếu có lỗi phát sinh.
Các đoạn code nhỏ được thử nghiệm một cách cô lập ban đầu. Tích hợp và kiểm tra hệ thống (Integration and system testing). Các lập trình viên sẽ tích hợp code và kiểm tra sự tương tác của toàn bộ hệ thống (bao gồm verification-kiểm tra trước khi có sản phẩm và validation-kiểm tra sau khi có sản phẩm) để xem các đơn vị có vận hành trơn tru hay không, nếu có trục trặc thì sẽ tiến hành sửa lỗi. Giai đoạn này rất quan trọng vì chất lượng của phần mềm có tốt hay không là do chất lượng của quá trình kiểm tra.
Phần mềm tốt sẽ dẫn đến khách hàng hài lòng. Chuyển giao và bảo trì (Operation and maintenance). Ở phần cuối, sau khi chắc chắn đã sửa hết lỗi và vận hành trơn tru, các lập trình viên sẽ tiến hành chuyển giao cho khách hàng để đưa vào sử dụng, chạy hệ thống trong môi trường thực tế. Công đoạn bảo trì sửa chữa - nâng cấp sẽ được thực hiện nếu có lỗi phát sinh trong quá trình sử dụng hoặc nếu muốn nâng cao năng suất hệ thống thì các lập trình viên sẽ dựa trên yêu cầu của khách hàng để tiến hành bảo trì nâng cấp, cải tiến phần mềm.
Sự phụ thuộc của các giai đoạn. Trong mô hình này, hoạt động phát triển phần mềm được chia thành các giai đoạn khác nhau và từng giai đoạn bao gồm hàng loạt các nhiệm vụ và có các mục tiêu khác nhau. Một giai đoạn bắt buộc được hoàn thành trước khi bắt đầu giai đoạn tiếp theo. Nói tóm lại, không có sự chồng chéo nào trong mô hình thác nước.
Ưu điểm và nhược điểm. ● Đây là mô hình đơn giản, dễ áp dụng và quản lí, quy trình rõ ràng theo từng bước. ● Các tiêu chí đầu vào và đầu ra được xác định rõ ràng nên dễ dàng trong công tác kiểm tra chất lượng. ● Hoạt động hiệu quả trong các dự án nhỏ, với các yêu cầu rõ ràng.
● Có nhiều tài liệu cung cấp cho khách hàng. Nhược điểm. ● Không phải mô hình lý tưởng cho các dự án lớn và dài ngày. ● Không hiệu quả đối với những dự án đối mặt với các yêu cầu không rõ ràng từ đầu.
● Khó thích ứng với thay đổi bao gồm yêu cầu, kế hoạch, phạm vi dự án… ● Độ trực quan thấp và giá trị chuyển giao chậm khi đến cuối chu trình người dùng mới nhìn thấy và sử dụng sản phẩm. Lý do lựa chọn mô hình. Do thời gian có hạn và số lượng người thực hiện hạn chế nên sản phẩm lần này chúng em đưa ra chỉ có quy mô nhỏ với mục đích học hỏi và tập ứng dụng thực tiễn. Vì vậy nên mô hình thác nước sẽ là lựa chọn ổn định để chúng em triễn khai và thực thi so với quy trình tiếp cận SCRUM.
Mô tả nghiệp vụ các công cụ, công nghệ sử dụng trong đồ án 1. Odoo là một phần mềm ERP mã nguồn mở (open-source), nghĩa là khả năng tùy chỉnh và phát triển các tính năng của phần mềm này là vô hạn. Cụ thể hơn, ngoài các phân hệ hay module cơ bản của Odoo như POS, CRM, quản lý kho, quản lý nhân sự,… thì Odoo cho phép bạn hoàn toàn chỉnh sửa hay thêm bớt những tính năng hoặc tạo ra các phân hệ mới mà bạn mong muốn. Ngoài ra, Odoo còn cung cấp các tính năng bảo mật cho các cộng đồng về công nghệ kinh doanh và phát triển phần mềm trên toàn thế giới.io là một website cung cấp nền tảng cho người dùng vẽ các biểu đồ, mô hình, sơ đồ từ đơn giản đến phức tạp hơn.io được nhóm sử dụng để hổ trợ vẽ các sơ đồ như BFD, DFD, class, usecase, sequence, workflow,… 1.
Kế hoạch thực hiện. CHƯƠNG II .