Xây dựng phần mềm quản lý phân phối hàng hóa cho doanh nghiệp nhỏ và vừa

[BAU69] - Định nghĩa 2: Công nghệ phần mềm là: 1 Sự áp dụng một cách tiếp cận định lượng, có qui trình và có tính hệthống nhằm phát triển, vận hành và duy trì phần mềm 2 Nghiên cứu các p

MỤC LỤC

MỤC LỤC 1

A Lời mở đầu 2

I/ Cơ sở lí thuyết 3

1.1 Công nghệ phần mềm 3

1.2 Các mô hình phát triển phần mềm 6

1.2.1 Mô hình tuyến tính 6

1.2.2 Mô hình chế thử (Prototyping Model) 7

1.2.3 Mô hình phát triển nhanh (Rapid Application Development – RAD) 8

1.2.4 Các mô hình tiến hóa: tiến hoá, xoắn ốc, phát triển đồng thời 8

1.2.5 Mô hình lắp ráp hướng thành phần (Component assembly Model) 11

1.3 Quản lí dự án phần mềm 12

II/ Bài tập thực tế 20

2.1 Kế hoạch dự án (Project plan) 20

2.1.1 Mô tả ngắn gọn dự án 20

2.1.2 Ước lượng các khoảng thời gian 22

2.2 Lựa chọn mô hình, phương pháp phát triển 23

2.2.1 Lựa chọn mô hình phát triển dự án 23

2.2.2 Phương pháp phân tích thiết kế áp dụng trong phần mềm 25

2.3 Tài liệu phân tích đặc tả yêu cầu 26

2.3.1 Yêu cầu chức năng: 26

2.3.2 Yêu cầu phi chức năng 26

2.3.3 Yêu cầu về giao diện người dùng 27

2.3.4 Yêu cầu khả năng mở rộng trong tương lai 28

2.3.5 Một số yêu cầu khác 28

2.4 Phân tích hệ thống 29

2.4.1 Sơ đồ phân cấp chức năng 29

2.4.2 Sơ đồ luồng dữ liệu mức ngữ cảnh 29

2.4.3 Sơ đồ luồng dữ liệu mức đỉnh 30

2.4.4 Sơ đồ luồng dữ liệu mức dưới đỉnh 30

2.4.6 Mô hình ER 32

Mô hình dữ liệu quan hệ 33

2.5 Tài liệu thiết kế hệ thống 34

2.5.1 Mô tả tương tác giữa người dùng và hệ thống 34

2.5.2 Thiết kế hình dạng các trang màn hình 35

2.6 Tài liệu kiểm thử 39

2.6.1 Mục đích 39

2.6.2 Phạm vi kiểm thử 39

2.6.3 Ràng buộc test 40

2.6.4 Chiến lược kiểm thử 40

2.6.5 Các kiểu kiểm thử 41

2.6.5.1 Kiểm thử giao diện người sử dụng 41

2.6.5.2 Kiểm thử chức năng 41

2.6.5.3 Kiểm thử dữ liệu và tích hợp dữ liệu 43

2.6.5.4 Kiểm thử hiệu năng (Perfomence testing) 43

TÀI LIỆU THAM KHẢO 49

A Lời mở đầu

Trong kinh doanh hệ thống phân phối là một trong nhữngphần rất quan trọng đối với mỗi doanh nghiệp để đưa sản phẩm củamình ra thị trường đến người tiêu dùng

Với sự phát triển ngày một cao về công nghệ và sự thay đổi đa dạngtrong tâm lý, nhu cầu của người tiêu dùng, nền kinh tế gặp nhiều khókhăn việc phân phối hàng hóa một cách hợp lý càng trở thành vấn đềđược các doanh nghiệp quan tâm hiện nay

Với đề tài “ Xây dựng phần mềm quản lý phân phối hàng hóa chodoanh nghiệp nhỏ và vừa” nhóm chúng tôi đã tiến hành xây dựng nênphần mềm theo quy trình qua các khâu bắt đầu với việc phân tích vàkết thúc là quá trình kiểm thử

- Định nghĩa 1: Công nghệ phần mềm là sự nghiên cứu những nguyên

tắc công nghệ đúng đắn nhằm tạo ra phần mềm một cách kinh tế, tin cậy

và làm việc hiệu quả trên các máy thực [BAU69]

- Định nghĩa 2: Công nghệ phần mềm là:

1) Sự áp dụng một cách tiếp cận định lượng, có qui trình và có tính hệthống nhằm phát triển, vận hành và duy trì phần mềm

2) Nghiên cứu các phương pháp tiếp cận sự dụng trong 1) [IEEE’93]

Như vậy, “Công nghệ phần mềm là lĩnh vực khoa học về các

phương pháp luận, kỹ thuật và công cụ tích hợp trong quy trình sản xuất và vận hành phần mềm nhằm tạo ra phần mềm với những chất lượng mong muốn “.

Để hiểu rõ về công nghệ phần mềm, người ta phân nó thành 4 tầng : tầng chất lương, tầng qui trình, tầng phương pháp và tầng công cụ

Qui trình Phương pháp Công cụ

Nền tảng của Công nghệ phần mềm là qui trình Qui trình địnhnghĩa một khung làm việc cho một tập các qui trình chủ yếu (KPA –Key Process Area) Nó tạo nên các cơ sở để quản lý các dự án phầnmềm và thiết lập các ngữ cảnh để áp dụng các phương pháp kỹ thuật:

mô hình, dữ liệu, báo biểu,…Phương pháp phần mềm nhằm cung cấpcác kỹ thuật để chế tác phần mềm bao gồm:

- Phân tích yêu cầu người dùng

1.1.2 Quy trình phát triển phần mềm

Quy trình phát triển phần mềm là một cấu trúc bao gồm tập hợp các

thao tác và các kết quả tương quan sử dụng trong việc phát triển để sản

xuất ra một sản phẩm phần mềm Các thuật ngữ tương tự là vòng đời

phần mềm và quy trình phần mềm Đây được coi là một thành phần tập

con của vòng đời phát triển hệ thống

Tiêu điểm chất lượng

Vòng đời phần mềm là thời kỳ tính từ khi phần mềm được sinh ra cho đến

khi chết đi (từ lúc hình thành đáp ứng yêu cầu, vận hành, bảo dưỡng cho đếnkhi loại bỏ không dùng nữa

Quy trình phần mềm (vòng đời phần mềm) được phân chia thành các pha

chính: phân tích, thiết kế, chế tạo, kiểm thử, bảo trì Biểu diễn các pha cókhác nhau theo từng người

Có một số mô hình cho việc xây dựng các quy trình phát triển phầnmềm, mỗi mô hình mô tả các phương thức cũng như các nhiệm vụ hoặcthao tác cần được thực hiện trong cả quá trình Mô hình vòng đời tiêubiểu là mô hình thác nước (WaterFall Model) do Boehm đề xuất

Có 4 thao tác là nền tảng của hầu hết các quy trình phần mềm là:

● Đặc tả phần mềm: Các chức năng của phần mềm và điều kiện để nó hoạt động phải được định nghĩa

● Sự phát triển phần mềm: Để phần mềm đạt được đặc tả thì phải có quy trình phát triển này

Xác định yêu

cầu hệ thống

Kiểm chứng

Xác định yêu cầu phần mềm Kiểm chứng

Thiết kế căn bản Kiểm chứng

Thiết kế chi tiết Kiểm chứng

Lập trình

Gỡ lỗi

Kiểm thử Chạy thử

Vận hành Bảo trì Kiểm chứng lại

● Đánh giá phần mềm: Phần mềm phải được đánh giá để chắc chắn rằng

mô hình phát triển tiêu biểu

1.2.1 Mô hình tuyến tính

Mô hình tuyến tính hay còn gọi là tuần tự (Hình 2.4) khi mà cácpha được thực hiện một cách kế tiếp nhau, hết pha này đến pha khác Đây là mô hình thác nước kinh điển

Công nghệ học

Hệ thống / Thông tin

- Kỹ nghệ Hệ thống thông tin và mô hình hóa (InformationSystem Enginering and Modeling) nhằm thiết lập các yêu cầu, ánh xạmột số tập con các yêu cầu sang phần mềm trong quá trình tương tácgiữa phần cứng, người dùng con người và cơ sở dữ liệu.

1.2.2 Mô hình chế thử (Prototyping Model)

Trong thực tế, không phải lúc nào cũng có sẵn các nhu cầu vềphần mềm từ khía khách hàng Các doanh nghiệp phần mềm cần chủđộng tạo các kích thích, các nhu cầu cho khách hàng Một mô hình kháthích hơp cho cách tiếp cận này là mô hình chế thử

Theo mô hình này, bản mẫu được thiết kế như một “hệ sơ khai”nhằm thâu tóm yêu cầu người dùng Vì thế, các bản mẫu cần được thiết

kế nhanh, đơn giản, chưa cần tốt miễn sao thu thập được ý kiến củakhách hàng về sản phẩm sẽ được sản xuất mà họ chưa hình dung rađược

Nghe Khách

trình bày

Tạo / sửa bản mẫu

Khách kiểm tra bản mẫu

1.2.3 Mô hình phát triển nhanh (Rapid Application Development – RAD)

Là qui trình phát triển phần mềm gia tăng, tăng dần từng bướcvới mỗi chu trình phát triển rất ngắn (60-90 ngày) Ý tưởng chính là xâydựng dựa trên hướng thành phần (Component-based construction) vớikhả năng tái sử dụng Theo mô hình này, việc phát triển sẽ gồm một sốnhóm (teams), mỗi nhóm làm 1 RAD theo các pha: Mô hình nghiệp vụ,

Mô hình dữ liệu, Mô hình xử lý, Tạo ứng dụng, Kiểm thử và đánh giá

Mô hình này cũng bộc lộ một số hạn chế:

i) Cần một đội ngũ đông đảo để chia thành các nhóm

ii) Giao kèo phải chặt chẽ, nếu không dự án có thể bị đổ bể

iii) Các ứng dụng phải có tính mô đun hoá

iv) Các ứng dụng có tính mạo hiểm cao thì không nên dùng

1.2.4 Các mô hình tiến hóa: tiến hoá, xoắn ốc, phát triển đồng thời

Data Modeling

Data Modeling

Process Modeling

Process Modeling

Application Generation

Application Generation

Business Modeling

Data Modeling

Data Modeling

Process Modeling

Process Modeling Application Generation

Application Generation

Business Modeling

Data Modeling

Data Modeling

Process Modeling

Process Modeling Application Generation

Application Generation

Business Modeling

Data Modeling

Data Modeling

Process Modeling

Process Modeling

Application Generation

Application Generation

Business Modeling

Data Modeling

Data Modeling

Process Modeling

Process Modeling

Application Generation

Application Generation

Cách làm này sử dụng một qui trình lặp, cho phép các kỹ sư phầnmềm phát triển tăng dần, các phiên bản sau sẽ hoàn thiện hơn phiên bảntrước sau mỗi một chu trình lặp Trong phần dưới đây chúng ta sẽ xemxét 3 mô hình: Mô hình gia tăng, mô hình xoắn ốc và mô hình phát triểnđồng thời.

1.2.4.1 Mô hình gia tăng (Incremental Model)

Mô hình gia tăng là sự kết hợp các yếu tố của mô hình tuyến tính với

ý tưởng lặp của mô hình chế thử Mỗi mạch tuyến tính của qui trìnhcung cấp một sản phẩm (Hình 2.7) Mạch đầu tiên cung cấp một số chứcnăng cơ bản nào đó, mạch tiếp theo sẽ gia tăng thêm một số chức năngkhác,… mạch cuối cùng cung cấp một sản phẩm hoàn thiện, đáp ứngyêu cầu người dùng Tuy rằng trong mô hình này, các kỹ sư phần mềm

áp dụng tư tưởng lặp của mô hình chế thử song nó lại khác cơ bản vềsản phẩm Mỗi mạch của nó tạo ra một sản phẩm dùng được trong khi

mô hình chế thử thì không quan tâm ngay đến sản phẩm

Hình 2.7 Mô hình gia tăng

Ph©n tÝch ThiÕt kÕ LËp tr×nh KiÓm thö Ph©n tÝch ThiÕt kÕ LËp tr×nh KiÓm thö

Ph©n tÝch ThiÕt kÕ LËp tr×nh KiÓm thö Ph©n tÝch ThiÕt kÕ LËp tr×nh KiÓm thö

Xuất xưởng 3

1.2.4.2 Mô hình xoắn ốc (Spirral Model)

Mô hình xoắn ốc do Boehm đề xướng, kết hợp bản chất lặp của

mô hình chế thử được giám sát với tính hệ thống của mô hình tuyếntính Các hoạt động chính trong qui trình mô hình được biểu điễn trênhình 2.8

Mô hình xoắn ốc là một cách tiếp cận hiện thực để phát triểncác phần mềm và hoặc các hệ thống lớn Vì phần mềm được phát triểntheo sự tiến hoá, khách hàng và nhà phát triển hiểu nhau tốt hơn và cácrủi ro sẽ được giảm thiểu sau mỗi lần tiến hoá Việc giảm thiểu rủi ro lànhờ cách tiếp cận của mô hình chế thử và quan trọng hơn nhà pháttriển có thể áp dụng chế thử trong bất kỳ giai đoạn nào

Hạn chế lớn nhất của mô hình này là khả năng thuyết phụckhách hàng về giảm thiểu tính rủi ro trong quá trình phát triển mặt

Giao tiếp khách hàng

Nâng cấp

Làm mới

Khái niệm

khác, mô hình này cũng chưa thật quen thuộc với các nhà phát triển nhưtrong mô hình tuyến tính hay chế thử.

1.2.4.3 Mô hình phát triển đồng thời (Concurrent Development Model)

Mô hình phát triển đồng thời đôi khi còn gọi là kỹ nghệ tươngtranh Mô hình này có thể được biểu diễn như là một tập các hoạt động

kỹ thuật chủ yếu, các nhiệm vụ cùng một tập các trạng thái

Trong thực tế, mô hình này là mô thức cho sự phát triển của môhình “Khách-Chủ” (Client-Server) Theo nhiều chuyên gia, mô hình này

có thể áp dụng cho tất cả các dạng phát triển phần mềm thay vì pháttriển một chuỗi các hoạt động thì người định nghĩa một mạng các hoạtđộng và các hoạt động này tồn tại đồng thời trên mạng

1.2.5 Mô hình lắp ráp hướng thành phần (Component assembly Model)

Mô hình này dựa vào mô thức hướng đối tượng kết hợp với qui trình phát triển của mô hình xoắn ốc

Khách hàng

Xác định thành phần ứng viên

Tìm thành phần

từ thư viện

Lấy thành phần nếu có Xây dựng

Đặt thành phần vào thư viện

Xây dựng bước lặp thứ n của hệ thống

Khái niệm thành phần ở đây có thể coi như các lớp được tạo ratrong các phát triển trước được sử dụng lại Chúng được lưu trữ trongcác thư viện lớp Khi cần phát triển, các kỹ sư phần mềm tìm trong thưviện phát triển nếu tìm thấy, họ lấy ra sử dụng, trường hợp ngược lại họ

sẽ phải phát triển Một mặt nó được dùng cho phần mềm đang pháttriển, mặt khác nó được luu trong thư viện chung

1.3.2.1 Những người tham gia

Trong quy trình phần mềm (và mọi dự án phần mềm) có sựtham gia của con người và được phân loại theo 5 nhóm:

1.Quản lý cao cấp (Senior manager): Là những người xác định các

vấn đề nghiệp vụ có ảnh hưởng quan trọng tới dự án

2.Quản lý dự án (Project/Technical manager): Là những người lập

kế hoạch, thúc đẩy, tổ chức và kiểm soát những người phát triển phầnmềm

3.Người đang hành nghề/Người phát triển phần mềm (Practioners):

Là những người sử dụng các kỹ năng về mặt kỹ thuật cần thiết để xâydựng một sản phẩm hoặc một ứng dụng

4.Khách hàng (Customer): Là những người đưa ra các yêu cầu cho

1.3.2.2 Lãnh đạo đội

Một cách nhìn khác về các đặc trưng xác định một người quản

lý dự án hiệu quả tập trung vào 4 điểm chính:

- Giải quyết vấn đề (Problem solving):

- Đồng nhất trong quản lý (Managerial identity):

- Thành tích (Achievement):

- Uy tín và xây dựng đội (Influence and team building)

1.3.2.3 Đội phần mềm (Software team)

Cấu trúc đội “tốt nhất” phụ thuộc vào cách quản lý trong tổchức của bạn, số lượng người tham gia đội, mức độ kỹ năng của họ và

độ khó của toàn bộ vấn đề Mantei đã đưa ra ba tổ chức đội tổng quátnhư sau:

- Phân quyền dân chủ (Democratic decentralized - DD)

- Quản lý dân chủ (Controlled decentralized - CD)

- Quản lý tập trung (Controlled Centralized - CC)

Mantei mô tả 7 nhân tố cho một dự án cần được xem xét khi lậpcấu trúc của các đội phát triển phần mềm như sau:

+ Mức độ khó khăn của vấn đề cần giải quyết

+ Kích thước của (các) chương trình theo số dòng mã nguồn hoặc theo các điểm chức năng (function point)

+ Thời gian đội sẽ làm việc cùng nhau (thời gian sống của đội)

+ Mức độ vấn đề có thể chia ra (mô-đun hóa)

+ Chất lượng và độ tin cậy cần có của hệ thống cần xây dựng

+ Mức độ không linh động của ngày bàn giao

+ Mức độ hòa đồng (giao tiếp) cần cho dự án

Constantine đề xuất bốn “mô hình tổ chức” cho các đội phát triển phần mềm như sau:

1 Mô hình đóng (Closed paradigm) xây dựng một đội theo phân cấp

truyền thống về quyền hạn (tương tự như đội CC)

2 Mô hình ngẫu nhiên (Random paradigm) xây dựng một đội lỏng lẻo

và phụ thuộc vào năng lực, sáng kiến của các thành viên trong đội

3 Mô hình mở (Open paradigm) xây dựng một đội theo cách để có được

những kiểm soát kết hợp với mô hình đóng nhưng cũng có nhiều đổimới khi sử dụng mô hình ngẫu nhiên C

4 Mô hình đồng bộ (Synchronous paradigm) phụ thuộc vào khả năng

phân chia của các vấn đề và tổ chức các thành viên trong đội làm việc trên các mảng công việc đã phân chia với ít mức độ liên lạc không nhiềugiữa họ

1.3.2.4 Các vấn đề về liên lạc và phối hợp

Có rất nhiều lý do gây ra trục trặc cho các dự án phần mềm:

Khả năng co dãn (scale) tình trạng không chắc chắn (Uncertainty),

khả năng thao tác giữa các phần (Interoperability) Những đặc trưng

này của phần mềm hiện tại – khả năng co dãn, tình trạng không chắcchắn và khả năng thao tác giữa các phần – là những thực tế của đờisống Để giải quyết chúng hiệu quả, một đội phát triển phần mềm phảithiết lập những phương thức hiệu quả để phối hợp con người làm việc.Kraul và Streeter đã khảo sát trên một tập các kỹ thuật phối hợp của dự

án và phân loại theo cách sau:

- Các hướng tiếp cận hình thức, chung, không riêng tư (Formal,

- Liên lạc điện tử (Electronic communication)

- Hoạt động mạng giữa các cá nhân với nhau (Interpersonal networking)

1.3.3 Sản phẩm

Chúng ta cần xem xét sản phẩm và vấn đề cần giải quyết tại thời điểm bắt đầu dự án Những điểm sau cần quan tâm:

Hoạt động quản lý dự án phần mềm đầu tiên chính là việc quyết định

phạm vi phần mềm (software scope) Phạm vi được xác định bằng cách

trả lời các câu hỏi sau:

Ngữ cảnh (Context) Làm thế nào để phần mềm được xây dựng phù

hợp với một hệ thống, sản phẩm hoặc ngữ cảnh nghiệp vụ lớn hơn vàkết quả của ngữ cảnh là ràng buộc gì cần có?

Các mục tiêu thông tin (Information objectives) Những đối tượng dữ

liệu nào khách hàng có thể nhìn thấy được được tạo ra như đầu ra củaphần mềm? Những đối tượng dữ liệu nào cần thiết cho đầu vào?

Chức năng và hiệu năng (Function and performance) Chức năng

nào mà phần mềm cần thực hiện để chuyển đổi từ đầu vào thành đầu ra?

Có yêu cầu đặc biệt gì về hiệu năng không?

Phân rã vấn đề Phân rã vấn đề (Problem decomposition), đôi khi

được gọi là phân chia (partitioning) hay chuẩn bị kỹ lưỡng vấn đề

(problem elaboration), là một hoạt động cốt lõi của công việc phân tích

yêu cầu phần mềm Trong suốt hoạt động đưa ra phạm vi phần mềm,không có sự phân rã toàn bộ vấn đề Hơn nữa, sự phân rã này được ápdụng thành hai lĩnh vực lớn: (1) chức năng cần được bàn giao và (2) quytrình sẽ được sử dụng để bàn giao chức năng đó

1.3.4 Qui trình

Mười mô hình được quan tâm và áp dụng tuỳ theo qui mô, loại dự án khác nhau:

- Mô hình tuần tự tuyến tính

- Mô hình nguyên mẫu

- Mô hình RAD

- Mô hình gia tăng

- Mô hình xoáy ốc

- Mô hình WINWIN xoáy ốc

- Mô hình phát triển dựa thành phần

- Mô hình phát triển song song

- Mô hình theo các phương pháp hình thức

- Mô hình với các kỹ thuật thế hệ 4

1.3.5 Dự án

Để quản lý một dự án phần mềm thành công, chúng ta cần phảibiết những nguyên nhân gì dẫn đến một dự án thất bại và những yếu tốnào dẫn đến sự thành công

1.3.5.1 Sự thất bại của dự án và các nguyên nhân

Một dự án mà:

• Không đạt được các mục tiêu của dự án, và/hoặc

• Bị vượt quá ngân sách ít nhất 30%

Tại sao dự án thất bại ?

Nguyên nhân

1.Cán bộ không hiểu các yêu cầu của khách hàng

không quen thuộc với phạm vi và sự phức tạp của dự án: 17%

thiếu thông tin: 21% quản lý dự án

không tốt: 32%

lý do khác: 12%

Không rõ các mục tiêu: 18%

2.Phạm vi của dự án không rõ ràng

3.Quản lý thay đổi yếu kém

4.Công nghệ được lựa chọn bị thay đổi

5.Các yêu cầu nghiệp vụ bị thay đổi

6.Hạn công việc không thực tế

- Bắt đầu bằng đối xử đúng với đúng quyền hạn

- Luôn quan tâm, chăm sóc định kỳ

- Luôn theo dõi ghi chép tiến trình

3 Sự hiện diện có thể là dối trá - xem xét lịch trình ẩn đằng sau

4 Phải hiểu rằng những con người khác nhau thì có những cách nhìn khác nhau, hãy đặt mình vào địa vị của họ

5 Thiết lập kế hoạch của bạn sao cho có thể chỉnh sửa dễ dàng

6.Đối mặt với từng sự kiện như là nó đã có từ trước

7 Sử dụng quản trị để hỗ trợ cho các mục đích của dự án

8 Thời gian mục tiêu đối với từng nhiệm vụ không được giống như đã nêu trong kế hoạch

9 Đọc lại phạm vi và các mục tiêu của dự án mỗi tuần 1 lần

Nguyên tắc 5W2H (Boehm)

- Tại sao hệ thống lại đang được phát triển (Why)?

- Cái gì sẽ được hoàn thành, khi nào (What, When)?

- Ai chịu trách nhiệm cho một chức năng nào đó (Who)?

- Chúng sẽ được tổ chức đặt ở đâu (Where)?

- Công việc sẽ được hoàn thành về mặt kỹ thuật và được quản lý như thế

nào (How)?

- Lượng tài nguyên cần thiết là bao nhiêu (How much)?

Nguyên tắc W5HH của Boehm có thể áp dụng mà không quan tâm đến kích thước và độ phức tạp của một dự án phần mềm Các câu hỏi trên đây cung cấp một phác thảo kế hoạch tốt cho người quản lý dự án và nhóm phần mềm

II/ Bài tập thực tế

Xây dựng phần mềm quản lý phân phối hàng hóa tại công ty X

2.1 Kế hoạch dự án (Project plan)

2.1.1 Mô tả ngắn gọn dự án

Tìm hiểu về cách tổ chức Quản lý phân phối hàng hóa tại công ty vớinhững nội dung chính sau :

Mặt khác cuối kỳ các cửa hàng cũng gửi lên hệ thống danh sách hàng tồn

Hệ thống sẽ cập nhật từng ngày và cuối kỳ các thông tin sản phẩm: thôngtin về danh mục sản phẩm : những sản phẩm mới, những sản phẩm tồn kỳtrước

*/ Phân phối hàng hóa:

Dựa trên danh mục hàng bán, danh mục hàng tồn, danh mục sản phẩmđược cập nhật hàng ngày và đơn hàng mỗi cửa hàng đưa lên Cuối kỳ sẽthực hiện lập kế hoạch phân phối qua hệ thống gửi lên Ban Giám Đốc.BGĐ sẽ đưa ra quyết định có kiểm duyệt hay không

Nếu không được duyệt bản kế hoạch phải lập lại, nếu bản kế hoạch được

sự đồng ý của BGĐ thì nhân viên sẽ lập phiếu xuất hàng trên cơ sở bản kếhoạch đã được kiểm duyệt

Sau khi lập phiếu xuất hàng sẽ tiến hành xuất hàng tới các chi nhánh dựatrên phiếu xuất hàng đi kèm

Trong kỳ kinh doanh xảy ra tình trạng có cửa hàng bán chạy (hết hàng), cócửa hàng lại bị ứ đọng nhiều hàng hóa Khi đó dựa trên danh mục sảnphẩm cung cấp, danh mục hàng bán, danh mục hàng tồn tại mỗi cửa hàngđược cập nhật thường xuyên trên hệ thống để thực hiện luân chuyển hànghóa giữa các cửa hàng Cửa hàng thừa hàng sẽ đề xuất phiếu luân chuyểnqua hệ thống, nhân viên sẽ lập phiếu luân chuyển và gửi qua hệ thốngphiếu xác nhận luân chuyển tới cửa hàng để thông báo hàng sẽ được luânchuyển (đến hoặc đi), hàng luân chuyển sẽ đưa tới cửa hàng.

*/ Báo cáo :

Sau mỗi kỳ kinh doanh dựa trên danh mục hàng tồn kho được nhân viêncập nhật trên hệ , cùng với các thông tin hàng bán được hệ thống kết xuấtbáo cáo hàng tồn, báo cáo doanh thu gửi Ban Giám Đốc qua hệ thống BanGiám Đốc nhận được sẽ đưa lại những ý kiến phản hồi qua hệ thống

2.1.2 Ước lượng các khoảng thời gian

* Từ 19/10 – 21/10: Lập kế hoạch dự án, lựa chọn mô hình để phát

triển dự án

Nhóm thực hiện : Nguyễn Việt Anh, Nguyễn Thị Mai Anh…

Kết quả nhận được : bản kế hoạch chi tiết về dự án và đưa ra được

mô hình phát triển dự án

* Từ 21/10- 25/10 : Phân tích đặc tả yêu cầu

Nhóm thực hiện : Bùi Thị Kim Anh, Nguyễn Tuấn Anh, Đỗ ThịÁnh, Bùi Thị Đào

Kết quả nhận được: tài liệu phân tích đặc tả yêu cầu của hệ thốngquản lý phân phối hàng hóa

* Từ 26/10-29/10 : Tài liệu thiết kế

Nhóm thực hiện : Vũ Hữu Cường, Nguyễn Văn Dân, Đinh MạnhCương

Kết quả : có được tài liệu mô tả chi tiết hoạt động, mối tương tácgiữa người sử dụng và hệ thống, cấu trúc của hệ thống.

* Từ 30/10- 4/11: Tài liệu kiểm thử

Nhóm thực hiện : Bùi Văn Công, Tống Thị Ngọc Bích, Cao ThịNgọc Anh

Kết quả: có được kế hoạch kiểm thử phần mềm để đáp ứng nhucầu là phần mềm hoạt động một cách ổn định và có hiệu quả, đáp ứngđúng yêu cầu của người sử dụng

2.2 Lựa chọn mô hình, phương pháp phát triển

2.2.1 Lựa chọn mô hình phát triển dự án

Thực hiện dự án này , chúng tôi lựa chọn mô hình thác nước

Mô hình phát triển : Mô hình thác nước

Sơ đồ :

Đây là mô hình phát triển phần mềm cổ điển nhất Mô hìnhnày đề nghị các hoạt động được tiến hành như các giai đoạn tách biệt,giai đoạn sau sẽ không bắt đầu chừng nào giai đoạn trước chưa hoànthành Sản phẩm đầu ra của giai đoạn trước trở thành đầu vào của giaiđoạn sau Mô hình thác nước là một mô hình của quy trình phát triểnphần mềm, trong đó quy trình phát triển trông giống như một dòngchảy, với các pha được thực hiện theo trật tự nghiêm ngặt và không

có sự quay lui hay nhảy vượt pha là :

- Phân tích và xác định các yêu cầu