Tải bản đầy đủ (.doc) (48 trang)

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

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (367.71 KB, 48 trang )

Nhóm 1

Công nghệ phần mềm

MỤC LỤC
1.3.2.3 Đội phần mềm (Software team)....................................................................13
2.4 Phân tích hệ thống ..............................................................................................28

A. Lời mở đầu
Trong kinh doanh hệ thống phân phối là một trong những
phần rất quan trọng đối với mỗi doanh nghiệp để đưa sản phẩm của
mì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ạng
trong 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 cho
doanh nghiệp nhỏ và vừa” nhóm chúng tôi đã tiến hành xây dựng nên
phầ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ử.

Trường ĐH Thương Mại

1


Nhóm 1

Công nghệ phần mềm

B. Nội dung


I/ Cơ sở lí thuyết
1.1. Công nghệ phần mềm
1.1.1 Công nghệ phần mềm là gì?
Công nghệ phần mềm là một công nghệ phân tầng. Có nhiều
định nghiã khác nhau về Công nghệ phần mềm, song ở đây ta xét 2 định
nghĩa tiêu biểu:
- Đị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ụ.
Công cụ
Trường ĐH Thương Mại

2


Nhóm 1

Công nghệ phần mềm


Phương pháp
Qui trình

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

Nền tảng của Công nghệ phần mềm là qui trình. Qui trình định
nghĩ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ần
mề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ấp
cá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
- Thiết kế hệ thống
- Lập trình
- Kiểm thử
- Bảo trì
Công cụ phần mềm nhằm cung cấp các hỗ trợ tự động, bán tự
động cho qui trình và phương pháp phần mềm. Khi các công cụ được
tích hợp, thông tin tạo bởi các công cụ này có thể được sử dụng bởi các
công cụ khác, thí dụ như thiết kế có sự hỗ trợ.
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

Trường ĐH Thương Mại

3



Nhóm 1

Công nghệ phần mềm

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.
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 đến
khi 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ần
mềm, mỗi mô hình mô tả các phương thức cũng như các nhiệm vụ hoặc
thao tác cần được thực hiện trong cả quá trình. Mô hình vòng đời tiêu
biể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.

Trường ĐH Thương Mại

4


Nhóm 1

Công nghệ phần mềm


● 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.
● Đánh giá phần mềm: Phần mềm phải được đánh giá để chắc chắn rằng
nó làm những gì mà khách hàng muốn.
● Sự tiến hóa của phần mềm: Phần mềm phải tiến hóa để thỏa mãn sự
thay đổi các yêu cầu của khách hàng.

1.2 Các mô hình phát triển phần mềm
Trong việc sản xuất phần mềm, phụ thuộc vào đặc trưng của
các phần mềm cần chế tác mà nhà phát triển sử dụng các mô hình phát
triển khác nhau: có mô hình thì tuyến tính, cái khác lại lặp, cái khác thì
lại gia tăng, tiến hoá,…. Trong phần dưới đây chúng ta sẽ xem xét 10
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ác
pha đượ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.

Trường ĐH Thương Mại

5


Nhóm 1

Công nghệ phần mềm

- Kỹ nghệ Hệ thống thông tin và mô hình hóa (Information
System 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ác

giữ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ủa
khách hàng về sản phẩm sẽ được sản xuất mà họ chưa hình dung ra
được.

Trường ĐH Thương Mại

6


Nhóm 1

Công nghệ phần mềm

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ước
với mỗi chu trình phát triển rất ngắn (60-90 ngày). Ý tưởng chính là xây
dựng dựa trên hướng thành phần (Component-based construction) với
khả 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

Trường ĐH Thương Mại

7


Nhóm 1

Công nghệ phần mềm

Cách làm này sử dụng một qui trình lặp, cho phép các kỹ sư phần
mề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ản
trước sau mỗi một chu trình lặp. Trong phần dưới đây chúng ta sẽ xem
xé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ình
cung cấp một sản phẩm (Hình 2.7). Mạch đầu tiên cung cấp một số chức
năng cơ bản nào đó, mạch tiếp theo sẽ gia tăng thêm một số chức năng
khác,… mạch cuối cùng cung cấp một sản phẩm hoàn thiện, đáp ứng
yê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
Trường ĐH Thương Mại

8


Nhóm 1

Công nghệ phần mềm

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ến
tính. Các hoạt động chính trong qui trình mô hình được biểu điễn trên
hì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ển
các phần mềm và hoặc các hệ thống lớn. Vì phần mềm được phát triển
theo sự tiến hoá, khách hàng và nhà phát triển hiểu nhau tốt hơn và các
rủ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át
triể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ục
khách hàng về giảm thiểu tính rủi ro trong quá trình phát triển. mặt

Trường ĐH Thương Mại


9


Nhóm 1

Công nghệ phần mề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ương
tranh.. 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át
triể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.

Trường ĐH Thương Mại

10


Nhóm 1


Công nghệ phần mềm

Khái niệm thành phần ở đây có thể coi như các lớp được tạo ra
trong các phát triển trước được sử dụng lại. Chúng được lưu trữ trong
cá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át
triển, mặt khác nó được luu trong thư viện chung.
1.3 Quản lí dự án phần mềm
1.3.1 Định nghĩa
Quản lý dự án là tổ chức, lập kế hoạch và thiết lập lịch trình dự án. Cụ
thể:
1.3.1.1Khái niệm dự án
Một dự án:
- Là riêng biệt, độc lập
- Có điểm bắt đầu và điểm kết thúc
- Có sản phẩm cụ thể cuối cùng
- Là duy nhất, hoặc về sản phẩm hoặc về môi trường của nó
1.3.1.2 Quản lý dự án
Quản lý dự án là để đưa ra một sản phẩm cuối cùng:
- Đúng hạn
- Trong phạm vi ngân sách hay nguồn tài chính cho phép

Trường ĐH Thương Mại

11


Nhóm 1


Công nghệ phần mềm

- Phù hợp theo các đặc tả
- Với một mức độ chất lượng để phục vụ các nhu cầu kinh doanh và đáp
ứng các tiêu chuẩn chuyên môn và kỳ vọng của công tác quản lý
1. 3.1.3 Các lĩnh vực của quản lý dự án
- Con người (People)
- Sản phẩm (Product)
- Qui trình (Process)
- Dự án (Project)
1.3.2 Con người
Những nhà quản lý tranh luận rằng con người là chủ chốt nhưng
hành động của họ đôi khi lại đi ngược với lời nói của họ. Trong phần
này, chúng ta sẽ đề cập đến những người tham gia (player) vào quy
trình phát triển phần mềm và cách thức mà họ được tổ chức để thực hiện
phát triển phần mềm hiệu quả.
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ần
mềm.

Trường ĐH Thương Mại

12



Nhóm 1

Công nghệ phần mề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ây
dự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
phần mềm và những cổ đông khác.
5. Người dùng cuối (End User): Là những người tác động tới phần
mềm khi phần mềm đó được phát hành để sử dụng.
Để đạt được hiệu quả cao thì đội dự án phải được tổ chức theo
cách phát huy tối đa khả năng và kỹ năng của mỗi người và đó là công
việc của người lãnh đạo đội.
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át
như sau:
- Phân quyền dân chủ (Democratic decentralized - DD).
- Quản lý dân chủ (Controlled decentralized - CD).
Trường ĐH Thương Mại


13


Nhóm 1

Công nghệ phần mềm

- 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ập
cấ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 đổi
mớ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ều
giữa họ.

Trường ĐH Thương Mại

14


Nhóm 1

Công nghệ phần mềm

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ắc
chắn và khả năng thao tác giữa các phần – là những thực tế của đời
sống. Để giải quyết chúng hiệu quả, một đội phát triển phần mềm phải
thiế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,
impersonal approaches)
- Các thủ tục hình thức giữa cá nhân với nhau (Formal, interpersonal
procedures)
- Các thủ tục không hình thức giữa các cá nhân với nhau (Informal,
interpersonal procedures)
- 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:

Trường ĐH Thương Mại

15


Nhóm 1

Công nghệ phần mềm

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ủa
phầ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 áp

dụng thành hai lĩnh vực lớn: (1) chức năng cần được bàn giao và (2) quy
trì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

Trường ĐH Thương Mại

16


Nhóm 1

Công nghệ phần mềm

- 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ải
biế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 ?
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%

lý do khác: 12%

quản lý dự án
không tốt: 32%
Không rõ các mục
tiêu: 18%

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

Trường ĐH Thương Mại

17


Nhóm 1

Công nghệ phần mềm

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ế
7. Khách hàng cản trở
8. Nhà tài trợ bị thay đổi
9. Thiếu cán bộ có kỹ năng thích hợp
10.

Các nhà quản lý lảng tránh các kinh nghiệm và các bài học tốt.

1.3.5.2 Các yếu tố thành công
- 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
- Ra quyết định đúng đắn, sáng suốt
- Tiến hành phân tích đúc rút bài học kết thúc dự án.
10 nguyên tắc vàng
1. Quản lý dự án thành công chính là vấn đề về con người nhưng không
được quên quản trị
2. Khám phá các nguồn hỗ trợ và chống đỡ
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
Trường ĐH Thương Mại

18


Nhóm 1


Công nghệ phần mềm

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
10.

Không ngạc nhiê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

Trường ĐH Thương Mại


19


Nhóm 1

Công nghệ phần mềm

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ới
những nội dung chính sau :
- Quản lý hàng hóa
- Phân phối sản phẩm
- Báo cáo ( doanh số, hàng tồn)
Chi tiết :
*/ Quản lý hàng hóa:
Công ty X có nhiều cửa hàng bán lẻ . Hàng ngày các cửa hàng tập hợp
hóa đơn bán hàng gửi lên hệ thống . Qua các thông tin từ hóa đơn bán
hàng này và dựa vào danh mục sản phẩm cung cấp tới từng cửa hàng hệ
thống sẽ thống kê lượng hàng bán được trong ngày và đưa vào danh mục
hàng bán.
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ông
tin 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ựa
trên phiếu xuất hàng đi kèm.

Trường ĐH Thương Mại

20


Nhóm 1

Công nghệ phần mề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ản
phẩ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àng
hó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ển
qua hệ thống, nhân viên sẽ lập phiếu luân chuyển và gửi qua hệ thống
phiếu xác nhận luân chuyển tới cửa hàng để thông báo hàng sẽ được luân
chuyể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ên
cậ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ất
báo cáo hàng tồn, báo cáo doanh thu gửi Ban Giám Đốc qua hệ thống. Ban
Giá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ống
quả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ạnh
Cương
Trường ĐH Thương Mại

21


Nhóm 1

Công nghệ phần mềm

Kết quả : có được tài liệu mô tả chi tiết hoạt động, mối tương tác
giữ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 nhu
cầ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ơ đồ :

Trường ĐH Thương Mại

22


Nhóm 1

Công nghệ phần mềm

Đây là mô hình phát triển phần mềm cổ điển nhất. Mô hình
nà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àn
thà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ển
phần mềm, trong đó quy trình phát triển trông giống như một dòng
chả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
Trường ĐH Thương Mại

23


Nhóm 1


Công nghệ phần mềm

- Thiết kế hệ thống và phần mềm
- Triển khai thực hiện
- Kiểm thử
- Vận hành và bảo trì.
Lý do lựa chọn: Quản lý phân phối hàng hóa là một dự án với
quy mô nhỏ, có những yêu cầu xác định về phần mềm vì thế mà
những thay đổi yêu cầu được giảm tới độ tối thiểu khi dự án bắt đầu
để vừa đảm bảo về chi phí, vừa đảm bảo về thời gian thực hiện dự án .
Mặt khác, phần mềm Quản lý phân phối hàng hóa cũng được
thực hiện theo từng giai đoạn đã được đặt ra (phần ước lượng các
khoảng thời gian và phân công công việc) .Theo đó, việc chuyển từ
pha này sang pha khác sẽ diễn ra chỉ sau khi các pha trước đó đã thực
hiện hoàn toàn thành công .
Chính vì những lý do trên mà nhóm quyết định lựa chọn mô hình
thác nước để phát triển dự án .
2.2.2 Phương pháp phân tích thiết kế áp dụng trong phần mềm
Sử dụng phương pháp hướng chức năng:
- Đây là cách tiếp cận truyền thống.
Quan tâm chủ yếu tới những thông tin mà hệ thống sẽ giữ gìn.
Chúng ta hỏi người dùng xem họ sẽ cần những thông tin nào, rồi
chúng ta thiết kế ngân hàng dữ liệu để chứa những thông tin đó, cung
cấp Forms để nhập thông tin và in báo cáo để trình bày các thông tin.
--> Tập trung vào thông tin và không mấy để ý đến những gì có thể
xảy ra với những hệ thống đó và cách hoạt động (ứng xử) của hệ
thống là ra sao

Trường ĐH Thương Mại


24


Nhóm 1

Công nghệ phần mềm

- Ưu điểm: đơn giản, là phương pháp tốt cho việc thiết kế ngân hàng
dữ liệu và nắm bắt thông tin,
- Nhược điểm:
+ Áp dụng cho việc thiết kế ứng dụng lại có thể khiến phát sinh nhiều
khó khăn.
+ Không phù hợp với hệ thống thường xuyên thay đổi.

2.3 Tài liệu phân tích đặc tả yêu cầu
2.3.1 Yêu cầu chức năng:

TT

Tên chức
năng

Mô tả chi tiết
Thống kê hàng bán được của từng chi

1

Quản lý

nhánh


hàng hóa

Thống kê hàng tồn của từng chi nhánh
Cập nhật sản phẩm
Lập KH phân phối

2

Phân

Lập phiếu xuất hàng

phối

Xuất hàng

hàng hóa

Luân chuyển hàng hóa giữa các đại lý
Cho phép kết xuất các báo cáo doanh thu,

3

Trường ĐH Thương Mại

Báo cáo

hàng tồn


25


×