Phát triển hệ quản trị mua bán hàng và bảo hành sản phẩm trong hệ thống hoạch định nguồn lực doanh nghiệp

1

MC LC
MC LC.

1

DANH MC VIT TT..

4

M U...

5

CHNG 1. TNG QUAN V Mễ HèNH HểA PHN MM V H
THNG QUN TR NGUN LC DOANH NGHIP.
1.1. Tng quan v mụ hỡnh húa .
1.1.1.

Khỏi

nim

tru

tng

hoỏ..
1.1.2.

Khỏi

nim

mụ

hỡnh

v

mụ

hỡnh

hoỏ

..
1.1.2.1. Khỏi nim v mụ hỡnh hoỏ...........................................................
1.1.2.2. Mc ớch ca mụ hỡnh hoỏ..
1.1.3. Phơng pháp mô hình hoá ....

7
7
7
8
8
8
8
10
10

11

1.1.4. Ngụn ng mụ hỡnh hoỏ... 11
1.1.5. Nguyờn tc mụ hỡnh hoỏ.

12
12

1.2. Mụ hỡnh hoỏ tin trỡnh phỏt trin phn mm 13
1.2.1. Tin trỡnh phỏt trin phn mm. 14
1.2.2. Các mô hình phát triển HTTT cơ bản nhất...........................................

14
14

I.2.2.1. Mô hình Vòng đời cổ điển...........................................................

15

I.2.2.2. Mô hình làm bản mẫu .................................................................

16

I.2.2.3. Mô hình xoắn ốc...........................................................................
1.2.3. Cỏc mụ hỡnh phỏt trin phn mm theo k ngh hng cu trỳc.......

17

1.2.3.1. Mụ hỡnh ca khụng gian phỏt trin mt h thng ........................
1.2.3.2. Mụ hỡnh c t cỏc giai on phỏt trin mt h thng..................

17

1.2.3.3. S quỏ trỡnh phỏt trin h thng...............................................
1.2.4. Cỏc mụ hỡnh phỏt trin phn mm theo k ngh hng i 17
tng........................................................................................................................ 18


2
1.2.4.1. Ngôn ngữ mô hình hoá hợp nhất (Unified Modeling Language- UML)

19
19

………………………………………………………………………………
1.2.4.2. Quy trình phát triển phần mềm hợp nhất (Unified Software

22

Development Procces) …………………………………………………………….

23
24

1.2.4.3. Mô hình hóa kiến trúc hệ thống trong UML……………………

1.2.5. Mô hình phát triển phần mềm theo kỹ nghệ hướng thành phần……... 25
1.2.5.1. Mô hình thành phần………………………………………………..

25

1.2.5.2. Thực thi mô hình thành phần………………………………………

26

1.2.5.3. Vòng đời phần mềm………………………………………………..

28

1.2.5.4. Sơ đồ tổng thể phát triển phần mềm.................................................

28

1.2.5.5. Mô hình phát triển phần mềm hướng thành phần............................. 28
1.2.6. Mô hình phát triển phần mềm theo kỹ nghệ hướng dịch vụ (SOA).....
1.2.6.1.

Một số đặc

trưng phân

biệt

của

SOA...............................................
1.2.6.2. Mô hình kiến trúc của SOA..............................................................

29
29

30
30

1.3. Tổng quan về hệ thống quản trị nguồn lực doanh nghiệp………………… 30
1.3.1. Khái niệm................................................................................................

31

1.3.2. Chức năng của ERP...............................................................................
1.3.3. Sự khác biệt giữa ERP với kế toán truyền thống……………………..
1.3.4.Thực trạng sử dụng ERP ở Việt Nam…………………………………. 33
1.3.5. Khái quát về CRM……………………………………………………... 33
1.3.5.1. Khái niệm về CRM……………………………………………….

33

1.3.5.2. Các chức năng của CRM………………………………………...

36
36

CHƯƠNG 2. ỨNG DỤNG MÔ HÌNH HÓA HƯỚNG CẤU TRÚC TRONG
QUÁ TRÌNH PHÁT TRIỂN HỆ THỐNG QUẢN TRỊ MUA BÁN HÀNG
VÀ BẢO HÀNH SẢN PHẨM……………………………………………………
2.1. Hệ thống quản trị mua bán hàng và bảo hành sản phẩm ………………...
2.1.1. Quy trình mua hàng…………………………………………………….
2.1.2. Quy trình bán hàng……………………………………………………..
2.1.2.1. Bản chất của bán hàng………………………………………...….

37

39
39
40
40
41
42


3

2.1.2.2. Phân loại bán hàng........................................................................

42

2.1.2.3. Quản trị bán hàng………………………………………………...

43

2.1.2.4. Quy trình bảo hành sản phẩm............................................................

43

2.2. Các mô hình quản lý .......................................................................................

44

2.2.1. Mô hình quản lý khách hàng tiềm năng.................................................
2.2.2.

Mô

hình

quản

lý

tổ

chức..........................................................................
2.2.3. Mô hình quản lý hợp đồng.......................................................................

44
44
44
45
46
47

2.2.4. Mô hình quản lý bán hàng.......................................................................
2.2.5. Mô hình quản lý cơ hội............................................................................
2.2.6. Mô hình quản lý chiến dịch.....................................................................

47
50
50
51
52

2.3. Các mô hình nghiệp vụ………………………………………………………

52

2.3.1. Mô hình ngữ cảnh ……………………………………………………... 68
2.3.2. Mô hình phân cấp chức năng …………………………………………. 68
2.3.2.1. Phân tích xác định chức năng……………………………………..

68

2.3.2.2. Sơ đồ phân cấp chức năng ………………………………………..

69

2.3.3. Ma trận cân đối E_F...............................................................................

69

2.4.Các mô hình phân tích .....................................................................................

69

2.4.1.Các mô hình phân tích xử lý....................................................................

70

2.4.2. Các mô hình phân tích dữ liệu................................................................

70

2.4.2.1. Danh sách các thực thể ……………………………..................... 71

2.4.2.2. Các mối quan hệ ………………………………………………... 72
2.5. Các mô hình thiết kế…………………………………………………………

73

2.5.1. Mô hình thiết kế CSDL vật lý…………………………………………..

74

2.5.2. Mô hình tổ chức dữ liệu và hệ thống…………………………………..

76

2.5.2.1. Mô hình tổ chức dữ liệu…………………………………………..

77

2.5.2.2. Mô hình hệ thống…………………………………………………

79


4

CHƯƠNG 3. CHƯƠNG TRÌNH THỬ NGHIỆM……………………………..
3.1. Môi trường thử nghiệm……………………………………………………...
3.2. Một số giao diện chương trình........................................................................
3.2.1. Giao diện đăng nhập……………………………………………………
3.2.2. Giao diện trang chủ……………………………………………………..
3.2.3. Giao diện quản lý mua bán hàng………………………………………

3.2.4.Giao diện quản lý chiến dịch………………………………………........
3.2.5. Giao diện quản lý khách hàng………………………………………....
3.2.6. Giao diện quản lý các hoạt động khác………………………………....
3.3. Đánh giá kết quả thử nghiệm………………………………………………..
KẾT LUẬN………………………………………………………………………..
TÀI LIỆU THAM KHẢO………………………………………………………..


5

DANH MỤC CÁC CHỮ VIẾT TẮT
CRM
CSDL
Đ/c
DN
ERP
HTTT
KH
KH
KSNB
NCC
NTD
OOP
PKH
PTTK
QAQC
TGĐ
TPKH
UML
Y/c

Customer Relationship Management - Quản lý Quan Hệ Khách Hàng
Cơ sở dữ liệu
Địa chỉ
Doanh nghiệp
Entepries Resoure Planning – Hoạch định nguồn lực doanh nghiệp
Hệ Thống thông tin
Khách hàng
Kế hoạch
Kiểm soát nội bộ
Nhà cung cấp
Người tiêu dùng
Object Oriented Programming - Lập trình hướng đối tượng
Phòng kế hoạch
Phân Tích Thiết kế
Quality Assurance Quality control – Kiểm tra đảm bảo chất lượng
Tổng giám đốc
Trưởng phòng kế hoạch
Unified Modeling Language- UML-Ngôn ngữ mô hình hoá hợp nhất
Yêu cầu


6

MỞ ĐẦU
Trong vài năm trở lại đây, với sự phát triển như vũ bão của công nghệ thông
tin đã mang lại cho các doanh nghiệp những phương thức kinh doanh mới, hiện đại
hơn, hiệu quả hơn. Tuy vậy, phổ biến trên thị trường phần mềm ứng dụng hiện nay
mới chỉ là các phần mềm áp dụng cho các hệ thống kế toán, quản lý công văn hay
giấy tờ, ít xuất hiện những hệ thống có khả năng bao quát toàn bộ quá trình kinh

doanh của doanh nghiệp.
Cùng với sự phát triển của công nghệ phần cứng và mạng máy tính thì giờ đây
ERP (Entepries Resoure Planning) được dịch là hoạch định nguồn lực doanh nghiệp,
đã nhanh chóng nhận được sự quan tâm và đầu tư của các doanh nghiệp, do những
lợi ích to lớn mà nó mang lại. ERP không chỉ giới hạn trong quản lý sản xuất, mà nó
bao trùm lên toàn bộ chức năng chính của doanh nghiệp.
Kế tiếp ERP thuật ngữ CRM (Customer Relationship Management) được
dịch là quản trị quan hệ khách hàng. Áp dụng CRM có nghĩa là mọi hoạt động của
doanh nghiệp luôn được xoay quanh khách hàng, hướng tới việc tăng cường mối
quan hệ khách hàng và làm hài lòng khách hàng. Về cơ sở lý thuyết CRM đưa ra
được những kiến thức cơ bản về quản lý quan hệ khách hàng, bao gồm các quá
trình từ tiếp thị bán hàng đến chăm sóc sau bán hàng để có được những khách hàng
thường xuyên.
Từ những tình trạng đang gặp phải của các doanh nghiệp trong nước cùng xu
thế phát triển của các doanh nghiệp nước ngoài và những nhu cầu thiết yếu phải sử
dụng công nghệ thông tin để làm công cụ hỗ trợ đắc lực cho các doanh nghiệp, xóa
bỏ những phương thức kinh doanh cổ hủ, lạc hậu. Tôi mạnh dạn lựa chọn đề tài:
“Phát triển hệ quản trị mua bán hàng và bảo hành sản phẩm trong hệ thống
hoạch định nguồn lực doanh nghiệp”.


7

Cấu trúc của luận văn gồm những nội dung chính sau đây:
MỞ ĐẦU
Phần này trình bày ý nghĩa và lý do chọn đề tài “Phát triển hệ quản trị mua
bán hàng và bảo hành sản phẩm trong hệ thống hoạch định nguồn lực doanh
nghiệp” để nghiên cứu trong luận văn của mình.Cũng trong phần này tôi sẽ giới
thiệu nội dung và cấu trúc của luận văn.
NỘI DUNG CHÍNH:

Chương I: TỔNG QUAN VỀ MÔ HÌNH HÓA PHẦN MỀM VÀ HỆ THỐNG
QUẢN TRỊ NGUỒN LỰC DOANH NGHIỆP

Chương này trình bày một số vấn đề về mô hình hóa phần mềm, lý thuyết
ERP và CMR trong quản lý doanh nghiệp.
Chương II: ỨNG DỤNG MÔ HÌNH HÓA HƯỚNG CẤU TRÚC TRONG QUÁ
TRÌNH PHÁT TRIỂN HỆ THỐNG QUẢN TRỊ MUA BÁN HÀNG VÀ BẢO HÀNH
SẢN PHẨM

Chương này trình bày và tập trung mô tả về các mô hình nghiệp vụ của quy
trình mua bán hàng và bảo hành sản phẩm sau bán hàng.
Chương III : CHƯƠNG TRÌNH THỬ NGHIỆM
Chương này trình bày cách thức xây dựng,sử chương trình thử nghiệm và
một số kết quả thu được từ chương trình thử nghiệm.
KẾT LUẬN
Tổng kết đề tài và đưa ra hướng nghiên cứu, phát triển tiếp theo.
PHỤ LỤC
Cung cấp thông tin về tài liệu tham khảo và sử dụng trong đề tài.


8

CHNG 1. TNG QUAN V Mễ HèNH HểA PHN MM V H THNG
QUN TR NGUN LC DOANH NGHIP
1.1. Tng quan v mụ hỡnh húa
1.1.1. Khỏi nim tru tng hoỏ
tỡm hiu v mt th gii phc tp, mi khoa hc thc nghim u phi vn dng mt
nguyờn lý c bn, ú l s tru tng hoỏ (Abstraction). Tru tng hoỏ l mt nguyờn lý ca
nhn thc, ũi hi phi b qua nhng sc thỏi (chi tit ca ch im) khụng liờn quan ti ch nh
hin thi, tp trung hon ton vo cỏc sc thỏi chớnh liờn quan ti ch nh ú (t in Oxford).

Theo Liberty J.,1998, trừu tợng là nguyên lý bỏ qua những khía cạnh của chủ thể
không liên quan đến mục đích hiện tại để tập trung đầy đủ hơn vào các khía cạnh còn
lại. Trừu tợng hoá là đơn giản hoá thế giới thực một cách thông minh. Nó cho khả
năng tổng quát hoá và ý tởng hoá vấn đề đang xem xét. Chúng loại bỏ đi các chi tiết d
thừa mà chỉ tập trung vào các điểm chính, cơ bản.
Trừu tợng là sự mô tả một cách khái quát một đối tợng thực và bỏ qua nhiều yếu
tố, nhiều mặt không quan trọng của nó. Sử dụng nguyên lý trừu tợng hoá có nghĩa là
thừa nhận thế gii thực là phức tạp, thay vì cố gắng hiểu biết toàn bộ bằng lựa chọn
một phần của vấn đề.
Theo Wasserman, Ký pháp trừu tợng mang tính tâm lý cho phép ta tập trung vào
một vấn đề ở một mức nào đó của sự khái quát, bỏ qua các chi tiết ở mức thấp ít liên
quan. Việc sử dụng sự trừu tợng cũng cho phép ta làm việc với các khái niệm và thuật
ngữ gần gũi trong môi trờng của vấn đề đặt ra mà không phải chuyển chúng thành một
cấu trúc không quen thuộc.
Tru tng húa l mt kh nng c bn ca con ngi trong vic gii quyt cỏc
vn phc tp. Nú l mt c ch c dựng biu din mt s vt phc tp tr
nờn n gin hn bng cỏch dựng mt s loi mụ hỡnh. Nu s tru tng c biu
din mc vt lý, chng hn nh mt s trờn giy hoc mt i tng vt lý, ngi
ta thng dựng thut ng mụ hỡnh.


9

1.1.2. Khỏi nim mụ hỡnh v mụ hỡnh hoỏ
1.1.2.1. Khỏi nim v mụ hỡnh hoỏ
Việc dùng mô hình để nhận thức và diễn tả một hệ thống đợc gọi là mô hình hoá.
Trong khoa học máy tính, mô hình hoá bắt đầu từ việc mô tả vấn đề, sau đó là mô tả giải
pháp vấn đề. Các hoạt động này còn đợc gọi là phân tích và thiết kế. Khi khảo sát hệ
thống, ngời ta su tập yêu cầu cho hệ thống, ánh xạ chúng thành yêu cầu phần mềm , từ
đó phát sinh mã trình, đảm bảo yêu cầu phù hợp với mã trình và khả năng chuyển đổi mã

trình ngợc lại thành yêu cầu. Tiến trình đó chính là thực hiện mô hình hoá.
1.1.2.2. Mc ớch ca mụ hỡnh hoỏ
Mục đích của mô hình hoá là để hiểu, để làm phơng tiện trao đổi, để hoàn chỉnh
hệ thống, hay nói rõ hơn:
a) Mụ hỡnh hoỏá giỳp ta hiu v thc hin c s tru tng, tng quỏt hoỏ cỏc
khỏi nim c s gim thiu phc tp ca h thng. Qua mụ hỡnh chỳng ta bit
c h thng gm nhng gỡ? v chỳng hot ng nh th no?.
b) Mụ hỡnh hoỏ giỳp chỳng ta quan sỏt c h thng nh nú vn cú trong thc t hoc
nú phi cú nh ta mong mun.
c) Mụ hỡnh hoỏ cho phộp chúng ta c t c cu trỳc v hnh vi ca h thng:
+ m bo h thng t c mc ớch ó xỏc nh trc.
+ Kim tra c cỏc quy nh v cỳ phỏp, ng ngha v tớnh cht ch v y
ca mụ hỡnh, khng nh c tớnh ỳng n ca thit k, phự hp vi yờu cu ca
khỏch hng.
d) Mụ hỡnh hoỏ l nhm to ra khuụn mu (template) v hng dn cỏch xõy dng h
thng; cho phộp th nghim, mụ phng v thc hin, hon thin theo mụ hỡnh.
1.1.3. Phơng pháp mô hình hoá
Phơng pháp mô hình hoá là một trong những phơng pháp quan trọng nhất để
nghiên cứu hệ thống. ý tởng của phơng pháp mô hình hoá là không nghiên cứu trực
tiếp đối tợng mà thông qua việc nghiên cứu một đối tợng khác tơng tự hay là hình


10

ảnh của nó mà có thể sử dụng đợc các công cụ khoa học. Kết quả nghiên cứu trên mô
hình đợc áp dụng vào cho đối tợng thực tế.
Kiểm tra mức độ phù
hợp
Hệ thống thực

Mô hình
1
điều chỉnh

áp dụng khi không cần
phải điều chỉnh

Kết quả nghiên
cứu mô hình

Kiểm nghiệm
4

đánh giá

Hình 1.1. Sơ đồ nguyên tắc hoạt động của phơng pháp mô hình hoá
Việc mô hình hoá thể hiện một tiến độ triển khai, bao gồm các bớc đi lần lợt, các
hoạt động cần làm. Mô hình hoá giữ một vai trò đặc biệt quan trọng khi nó trở thành
một công cụ trợ giúp. Đó là cơ sở tạo phần mềm giúp cho việc triển khai hệ thống thực
hiện đúng và nhanh.
Phng phỏp mụ hỡnh húa l phng phỏp tiờn tin. Nú giỳp chỳng ta hiu rừ hn v
h thng m chỳng ta ang xõy dng, to ra c hi cú th n gin húa v tỏi s dng.
Theo Booch G., Rumbaugh J. and Jacobson I., mụ hỡnh hoỏ mt h thng phi
thc hin theo c bn hng:
Kin trỳc
Cu trỳc tnh (d liu, thụng
tin c lu tr, x lý v cỏc
yu t to nờn h thng).

Cỏc chc nng, nhim v

hoc quỏ trỡnh x lý cỏc
nhim v ca h thng.
Cỏch ng x

Hình 1.2. Các hng mô hình hoá
Hng ca im xut phỏt s kộo theo phng phỏp cn la chn phỏt trin
phn mm. Nu ta bt u t bờn trỏi, ngha l tp trung vo chc nng phõn tớch


11

thì chúng ta thực hiện, phát triển phần mềm theo cách tiếp cận hướng chức năng.
Ngược lại, nếu bắt đầu từ bên phải, nghĩa là dựa vào dữ liệu là chính thì chúng ta sử
dụng phương pháp hướng đối tượng.
1.1.4. Ngôn ngữ mô hình hoá
Mô hình được biểu diễn theo một ngôn ngữ mô hình hoá. Ngôn ngữ mô hình hoá
bao gồm các ký hiệu (những biểu tượng được dùng trong mô hình) và một tập các quy
tắc chỉ cách sử dụng chúng. Các quy tắc này bao gồm:
- Cú pháp (Syntactic): cho biết hình dạng các biểu tượng và cách kết hợp chúng
trong ngôn ngữ.
- Ngữ nghĩa (Semantic): cho biết ý nghĩa của mỗi biểu tượng, chúng được hiểu
thế nào khi nằm trong hoặc không nằm trong ngữ cảnh của các biểu tượng khác.
- Mục đích (Pragmatic): định nghĩa ý nghĩa của biểu tượng để sao cho mục đích
của mô hình được thể hiện và mọi người có thể hiểu được.
1.1.5. Nguyên tắc mô hình hoá
Thông qua mô hình hoá, chúng ta sẽ giới hạn vấn đề nghiên cứu bằng cách chỉ tập
trung vào một khía cạnh của vấn đề vào một thời điểm. Mô hình hoá sẽ làm tăng độ dễ
hiểu của con người. Booch G., Rumbaugh J., Jacobson I., 1999, đã đưa ra 4 nguyên tắc
cơ bản về mô hình hoá:
1. Việc chọn mô hình nào để tạo lập có ảnh hưởng sâu sắc đến cách giải quyết

vấn đề và cách hình thành các giải pháp.
2. Mỗi mô hình biểu diễn hệ thống với mức độ chính xác khác nhau.
3. Mô hình tốt nhất phải là mô hình phù hợp với thế giới thực.
4. Không mô hình nào là đầy đủ. Mỗi hệ thống thường được tiếp cận thông
qua tập mô hình gần như độc lập nhau.


12

1.2. Mụ hỡnh hoỏ tin trỡnh phỏt trin phn mm
1.2.1. Tin trỡnh phỏt trin phn mm
Mt tin trỡnh phỏt trin phn mm l mt tp ca cỏc hot ng cn thit
chuyn cỏc yờu cu ngi dựng thnh mt h thng phn mm ỏp ng c cỏc yờu
cu t ra.
Tin trỡnh phỏt trin
phn mm

Yờu cu
ngi dựng

H thng
phn mm

Hỡnh 1.3. Quỏ trỡnh phỏt trin phn mm
Vũng i phỏt trin phn mm c chia thnh 4 pha: s b, son tho, xõy dng
v chuyn giao. Trong mi pha li chia thnh nhiu bc lp nh. Mi bc lp u
gm mt s cụng vic thc hin trn vn mt sn phm phn mm: lp cỏc mụ hỡnh
c t nghip v, xỏc nh yờu cu, lp cỏc mụ hỡnh phõn tớch d liu , x lý v hnh
vi, lp cỏc mụ hỡnh thit k, trin khai v kim th.
Năm 1996, Huff lần đầu tiên hệ thống hóa một số mô hình tiến trình phần mềm.

Sommerville, 2001, nhắc tới một số loại mô hình tiêu biểu:
- Mô hình thác nớc (waterfall model)
- Mô hình phát triển tiến hóa (evolutionary models): là mô hình trình phát triển
với quá trình lặp để xây dựng dần phần phềm. Mô hình loại này bao gồm mô hình làm
bản mẫu, mô hình xoắn ốc, mô hình tin trỡnh hp nht Rational-RUP, mô hình phát
triển tăng dần, phát triển ứng dụng nhanh-RAD.
- Phát triển hệ thống hình thức (formal system development): Một cách tiếp cận
dựa trên đặc tả hệ thống bằng toán học để chứng minh hay chuyển đổi nó thành chơng
trình nhờ các công cụ toán học chuyên dụng.
- Phát triển phần mềm theo hớng sử dụng lại (reuse oriented software
development): Quá trình phát triển tập trung vào việc tích hợp các thành phần đã có để
nhận đợc hệ thống, đáp ứng đợc các yêu cầu đặt ra.
phỏt trin HTTT, ngi ta cú nhiu hng phỏt trin. Cỏc hng chớnh ang
thnh hnh cú th k ra l:


13

1. Cỏc mụ hỡnh phỏt trin phn mm theo k ngh hng cu trỳc
2. Cỏc mụ hỡnh phỏt trin phn mm theo k ngh hng i tng
3. Cỏc mụ hỡnh phỏt trin phn mm theo k ngh hng thnh phn
4. Cỏc mụ hỡnh phỏt trin phn mm theo k ngh hng dch v
5. Cỏc mụ hỡnh phỏt trin phn mm theo k ngh hng in toỏn ỏm mõy.
Mi k ngh theo mt hng no ú u cú nhng th tri nht nh v nhng
hn ch no ú. Trong lun vn ny, chỳng ta s i sõu vo nghiờn cu k ngh hng
cu trỳc. Chỳng ta bt u t nhng kin thc tng quan nht v hng cu trỳc. Tip
ú gii thiu tng mụ hỡnh c th trong ú tin hnh mụ hỡnh húa tng khõu kho
sỏt, phõn tớch nghip v v logic. Cui cựng, chỳng ta s vn dng nú din t cỏc
mụ hỡnh thit k v ci t ỏp ng yờu cu ca bi toỏn c th.
1.2.2. Các mô hình phát triển HTTT cơ bản nhất

I.2.2.1. Mô hình Vòng đời cổ điển
Kỹ nghệ phần mềm đợc minh hoạ theo khuôn cảnh vòng đời cổ điển. Mô hình
vòng đời cổ điển đôi khi còn đợc gọi là mô hình thác nớc. Khuôn cảnh vòng đời yêu
cầu tiếp cận một cách hệ thống, tuần tự tới việc phát triển phần mềm, bắt đầu ở mức hệ
thống và tiến dần xuống phân tích, thiết kế, mã hoá, kiểm thử và bảo trì. Nh vậy khuôn
cảnh vòng đời bao gồm các hoạt động trong mô hình thác nớc sau:
Phân tích Kỹ
nghệ- Hệ
thống- Môi trư
ờng
Phân tích & định
rõ yêu cầu
Thiết kế hệ
thống & phần
mềm
Mã hoá

Kiểm thử đơn vị, tích
hợp & hệ thống
Vận hành và
Bảo trì


14

Hình 1.4. Mô hình Vòng đời cổ điển
I.2.2.2. Mô hình làm bản mẫu
Cách tiếp cận làm bản mẫu cho kỹ nghệ phần mềm là cách tiếp cận tốt nhất khi:
-Khách hàng xác định đợc mục tiêu tổng quát cho phần mềm, nhng cha xác
định đợc input và output

-Ngời phát triển không chắc về hiệu quả của thuật toán, về thích nghi hệ điều hành
Mô hình có thể lấy một trong 3 dạng:
1. Bản mẫu trên giấy hay trên máy mô tả giao diện ngời-máy dới dạng làm cho
ngời dùng hiểu đợc cách các tơng tác xuất hiện
2. Bản mẫu làm việc: cài đặt một tập con chức năng phần mềm mong muốn
3. Một chơng trình mà chỉ thực hiện nét cơ bản của tất cả chức năng mong
muốn nhng cần cải tiến thêm các tính năng khác tuỳ theo khả năng phát triển.
Dãy các sự kiện của khuôn cảnh làm bản mẫu đợc minh hoạ trong hình bên.
Bắt đầu

Kết thúc


Tập hợp yêu cầu
và làm mịn
xác định mục
tiêu tổng thể,
khảo sát thêm để
định rõ yêu cầu

Sản
phẩm

thiết kế
nhanh
(input,
output)

(vi chỉnh yêu
cầu)

Xây
dựng bản
mẫu

Làm mịn
bản mãu
Sản
phẩm

Đánh giá của
khách hàng
về bản mãu

Hình 1.5. Mô hình bản mẫu
Ngời phát triển và khách hàng gặp nhau và xác định mục tiêu tổng thể cho phần
mềm, xác định các yêu cầu nào đã biết, miền nào cần khảo sát thêm. Rồi đến việc
thiết kế nhanh. Thiết kế nhanh tập trung vào việc biểu diễn các khía cạnh của phần


15

mềm thấy đợc đối với ngời dùng (cách đa vào và định dạng đa ra). Thiết kế nhanh
xây dựng một bản mẫu ngời dùng đánh giá làm mịn các yêu cầu cho phần mềm.
Tiến trình lặp đi lặp lại xảy ra để cho bản mẫu đợc vi chỉnh thoả mãn yêu cầu của
khách, đồng thời giúp ngời phát triển hiểu kỹ hơn cần phải thực hiện nhu cầu nào.
I.2.2.3. Mô hình xoắn ốc
- Mô hình xác định 4 hoạt động chính:
Lập kế hoạch: xác định mục tiêu, giải pháp và ràng buộc
Phân tích rủi ro: phân tích các phơng án và xác định/ giải quyết rủi ro
Kỹ nghệ: phát triển sản phẩm mức tiếp theo

Đánh giá của khách hàng: khẳng định kết quả của kỹ nghệ
Tập hợp
yêu cầu ban
đầu và kế
hoạch dự
án
Kế hoạch
dựa trên ý
kiến của
khách hàng
Đánh giá
của
khách
hàng

Phân tích rủi ro
dựa trên yêu cầu
ban đầu
kế
hoạch

phân tích rủi
ro

Phân tích rủi ro dựa trên
phản ứng của khách hàng
Quyết định có tiếp tục hay
không ?
(cao điểm của việc phân
tích rủi ro)

Đánh giá của
khách

kỹ nghệ

Hướng tới hệ thống hoàn
chỉnh (quá trình làm mịn)
Bản mẫu ban đầu
Bản mẫu tiếp theo

Hỡnh 1.6. Cách tiếp cận thực tế nhất cho việc phát triển các hệ thống và phần mềm có
quy mô lớn
1.2.3. Cỏc mụ hỡnh phỏt trin phn mm theo k ngh hng cu trỳc
1.2.3.1. Mụ hỡnh ca khụng gian phỏt trin mt h thng
Có thể coi mỗi bớc trong quá trình PT_TK là một điểm trong không gian 3 chiều:
chiều thành phần của HTTT, chiều mức bất biến và chiều các giai đoạn phát triển. Việc
nghiên cứu PT-TK HTTT cần phải tiến hành theo mỗi chiều của không gian.


16

Mc vt lý

Y-chiu mc bt bin

Mc logic
Mc t chc

X-chiu cỏc thnh phn HTTT

Mc quan nim
Lp k hoch
phõn tớch
thit k
thc hin
chuyn giao
Bo trỡ

Thụng tin X lý Con ngi Thit b
(tnh)

(ng)

Z-chiu cỏc giai on phỏt trin
Hỡnh 1.7. S cỏc chiu ca khụng gian phỏt trin h thng
(ch m ch lnh vc nghiờn cu ca ngi PTTK)
Z- liờn quan n cỏch tip cn, phng phỏp lun, xỏc nh cỏc giai on, cỏc
im chuyn bt buc dn n mt li gii cú th hon ho hoc cha nhng kh thi
X-cho phộp xỏc nh thnh phn c bn ca mt HTTT: d liu, x lý,...
- Thụng tin: th hin mt tnh ca HTTT
- X lý: th hin mt ng ca HTTT
- Con ngi: quyt nh v can thip vo tin trỡnh khỏi nim hoỏ
- Thit b: thc hin cỏc x lý
Y-liờn quan n khỏi nim mc bt bin, cho phộp nhúm cỏc thụng s quyt
nh, ph thuc vo chu k sng, s la chn cụng c thc hin sn phm.
1.2.3.2. Mụ hỡnh c t cỏc giai on phỏt trin mt h thng
Các giai đoạn phát triển một hệ thống đợc đặc tả bởi đồ hoạ sau theo trình tự
thực tế I, II, III, IV trên cơ sở hai mức mô hình:

17

Mô hình HT
mức vật lý

Mô tả hoạt
động của hệ
thống hiện tại
Làm việc như
thế nào
(How to do)
I

Người sử dụng
muốn xử lý
trực tiếp

Mô tả hoạt
động hệ
thống mới
Làm việc
như thế nào
(How to do)
IV

Người sử dụng
và người phân
tích

Người sử dụng
mong muốn
Xác định bản
chất của hệ
thống

Mô hình HT
mức logic

Mô tả
hệ thống
hiện tại làm gì
(what to do)
II

Cân đối nhu
cầu và những
khả năng (các
nguồn lực)

Bổ sung
những yêu
cầu cho hệ
thống míi

Mô tả
hệ thống mới
làm gì
(what to do)
III

Người thiết kế
mong muốn

Hình 1.8. Các giai đoạn phát triển hệ thống
1.2.3.3. Sơ đồ quá trình phát triển hệ thống

1. Lập kế hoạch
dự án

6. Vận hành và
bảo trì
5. Cài đặt
chuyển đổi hệ
thống

TỔ CHỨC

4. Xây dựng
phần mềm thử
nghiệm

2. Phân tích hệ
thống
3. Thiết kế hệ
thống

H×nh 1.9. Qu¸ tr×nh ph¸t triÓn mét HTTT

18

1.2.4. Các mô hình phát triển phần mềm theo kỹ nghệ hướng đối tượng
1.2.4.1. Ngôn ngữ mô hình hoá hợp nhất (Unified Modeling Language- UML)
UML là ngôn ngữ trực quan được dùng trong quy trình phát triển các hệ thống
phần mềm. Nó là một ngôn ngữ đặc tả hình thức (formal specification language).
UML có một tập các phần tử và một tập các quy tắc riêng. hầu hết các phần tử của
UML là các đối tượng đồ hoạ như đường thẳng, hình chữ nhật, hình oval,… và
thường có nhãn kèm theo để tăng thông tin. Các quy tắc trong UML được mô tả trong
đặc tả UML như cú pháp trừu tượng (được biểu diễn như các sơ đồ và ngôn ngữ tự
nhiên), quy tắc hình thức (nằm trong ngôn ngữ ràng buộc đối tượng) và ngữ nghĩa.
Quy tắc xác định cách kết hợp giữa các phần tử.
Do UML là ngôn ngữ mô hình hoá chuẩn, ngôn ngữ mô hình đồ hoạ, trực quan,
vừa đặc tả vừa có cấu trúc, đồng thời lại là ngôn ngữ làm tài liệu nên đối với việc phát
triển phần mềm hướng đối tượng.
Mục đích chính của UML nhằm vào các hoạt động sau:
• Mô hình hóa được các hệ thống và sử dụng được tất cả các khái niệm hướng
đối tượng một cách thống nhất.
• Cho phép đặc tả, hỗ trợ để đặc tả tường minh mối quan hệ giữa các khái niệm
cơ bản trong hệ thống, đồng thời mô tả được mọi trạng thái hoạt động của hệ thống đối
tượng. Nghĩa là cho phép mô tả được cả mô hình tĩnh lẫn mô hình động một cách đầy
đủ và trực quan.
• Tận dụng được những khả năng sử dụng lại và kế thừa ở phạm vi diện rộng để
xây dựng được những hệ thống phức tạp và nhạy cảm như: các hệ thống động, hệ
thống thời gian thực, hệ thống nhúng thời gian thực...
• Tạo ra những ngôn ngữ mô hình hoá sử dụng được cho cả người lẫn máy tính.
1.2.4.2. Quy trình phát triển phần mềm hợp nhất (Unified Software Development
Procces)
UML được phát triển để đặc tả trong quá trình phát triển phần mềm, nhằm mô
hình hoá hệ thống. Quy trình phát triển phần mềm có sử dụng UML được gọi là quy

trình phát triển phần mềm hợp nhất.


19

Các đặc trưng của quy trình hợp nhất bao gồm:
• Quy trình hợp nhất bao gồm con người, dự án, sản phẩm, quy trình và công cụ.
Con người là những người tham gia dự án để tạo ra sản phẩm phần mềm theo một quy
trình với sự hỗ trợ của công cụ được cung cấp.
• Quy trình hợp nhất là quy trình phát triển phần mềm được hướng dẫn bởi các
ca sử dụng. Nghĩa là các yêu cầu của người sử dụng được mô tả trong các ca sử dụng,
là chuỗi các hành động được thực hiện bởi hệ thống nhằm cung cấp các dịch vụ, các
thông tin cho khách hàng. Các ca sử dụng bao gồm chuỗi các công việc được xem là
nền tảng để tạo ra mô hình thiết kế và cài đặt hệ thống.
• Quy trình hợp nhất cũng là quy trình tập trung vào kiến trúc, được lặp và phát
triển tăng trưởng liên tục.
• Quy trình hợp nhất không chỉ tạo ra một hệ thống phần mềm hoàn chỉnh mà
còn tạo ra một số sản phẩm trung gian như các mô hình ca sử dụng, mô hình khái
niệm, mô hình phân tích, mô hình thiết kế, mô hình triển khai, mô hình cài đặt và mô
hình kiểm thử.
1.2.4.3. Mô hình hóa kiến trúc hệ thống trong UML
Trong UML, kiến trúc của hệ thống phần mềm chuyên sâu (cho ta một cách nhìn
khái quát nhất về hệ thống phần mềm ở các góc độ khác nhau) được mô tả theo 5 loại
khung nhìn (views) khác nhau. Mỗi khung nhìn phản ánh về một khía cạnh của tổ chức
và cấu trúc của hệ thống, tập trung vào từng mặt cụ thể giúp cho ta hiểu và sử dụng hệ
thống tốt nhất. Mỗi khung nhìn thường được thể hiện trong một số sơ đồ nhất định.
Khung nhìn thiết kế/logic

Khung nhìn triển khai/bố trí
Khung nhìn

ca sử dụng

Khung nhìn tiến trình/tương
tranh

Khung nhìn cài đặt/thành phần

Hình 1.10. Mô hình hoá kiến trúc hệ thống


20



Khung nhìn ca sử dụng (Use case view): chứa các tác nhân, ca sử dụng, sơ

đồ ca sử dụng (khía cạnh tĩnh của khung nhìn) trong hệ thống. Chúng cũng có thể bao
gồm vài sơ đồ trình tự, sơ đồ cộng tác (khía cạnh động của khung nhìn) và gói.



Khung nhìn thiết kế (design view) Nó bao gồm các lớp, sơ đồ lớp, sơ đồ đối

tượng (khía cạnh tĩnh của khung nhìn), sơ đồ tương tác, sơ đồ hoạt động, sơ đồ biến
đổi trạng thái (khía cạnh động của khung nhìn) và các gói.



Khung nhìn tiến trình/tương tranh (process view) biểu diễn sự phân chia các

luồng thực hiện công việc, các lớp đối tượng cho các tiến trình và sự đồng bộ giữa các
luồng (thread) trong hệ thống.



Khung nhìn thành phần/cài đặt (component/implementation view) bao gồm

các thành phần (là mô-đun vật lý hay các file) để lắp ráp thành hệ thống vật lý. Khung
nhìn này hướng đến việc quản lý cấu hình của hệ thống.



Khung nhìn bố trí/triển khai (Deployment view) bao gồm các nút tạo nên kết

cấu phần cứng mà trên đó hệ thống vận hành. Khung nhìn này chủ yếu hướng đến sự
phân tán và cài đặt cụ thể của hệ thống, tức là liên quan đến triển khai vật lý của hệ thống.
1.2.5. Mô hình phát triển phần mềm theo kỹ nghệ hướng thành phần
1.2.5.1. Mô hình thành phần
Người ta thường dùng mô hình trừu tượng để mô tả các thành phần. Mô hình
này đưa ra một số yếu tố cơ bản: cú pháp (syntax), ngữ nghĩa (semantics) và kết hợp
(composition).
Một số thành phần phổ biến hiện nay như JavaBean, EJB, COM đều được mô
tả theo mô hình trừu tượng.
Ngôn ngữ lập trình cấu tạo nên thành phần sẽ quyết định cấu trúc. Trong các
thành phần hiện có, ngôn ngữ của thành phần là ngôn ngữ lập trình. Ví dụ: EJB tạo
bằng ngôn ngữ lập trình Java và là một Java class.
Hiện nay, thành phần có xu hướng chính là các đối tượng trong kiểu lập trình
hướng đối tượng. Các dịch vụ đầu ra là các phương thức (method). Các dịch vụ đầu
vào được quản lý và cung cấp bằng các bộ chứa (container)- nơi chứa các đối tượng.
Ví dụ: JavaBean được quản lý bởi bộ chứa như BeanBox và nó kết nối các

JavaBean thông qua sự kiện (event). Trong khi đó, EJB được quản lý bởi chương trình


21

máy chủ J2EE và EJB được tiếp cận thông qua 2 interface là “home” và “remote” hoặc
được gọi trực tiếp bởi máy chủ J2EE.
Trong phát triển phần mềm trên thành phần, sự kết hợp (composition) các
thành phần với nhau tạo thành hệ thống hoàn chỉnh là vấn đề cốt lõi (các thành phần
có thể kết hợp với nhau để tạo thành thành phần phức hợp). Vấn đề nảy sinh là hiện
nay chưa có một ngôn ngữ kết hợp đảm bảo tương thích về ngữ nghĩa và cú pháp cho
các thành phần EJB, COM...
Sự kết hợp thành phần có thể xảy ra ở hai giai đoạn chính trong vòng đời của
thành phần là thiết kế (design) và triển khai (deployment).
Một mô hình thành phần là một tập định nghĩa về các chuẩn để thực thi, làm tài
liệu và triển khai thành phần. Mô hình thành phần chỉ rõ làm thế nào xác định được
các giao diện và các phần tử phải có trong một định nghĩa giao diện.
Các mô hình thành phần là nền tảng cho phần mềm trung gian nhằm cung cấp
trợ giúp để thực thi các thành phần.
Một mô hình thành phần vận hành ở 2 mức khác nhau:
-Thứ nhất, một mô hình thành phần xác định cách cấu trúc một thành phần cá
thể như thế nào. Chẳng hạn, mô hình đối tượng thành phần của microsoft (COM) yêu
cầu mỗi thành phần phải cung cấp một giao diện ẩn.
-Thứ hai, một mô hình thành phần có thể quy định hành vi tổng thể trên một tập
các thành phần trong một hệ thống sẽ liên lạc và tương tác như thế nào với một tập
thành phần khác. Một mô hình thành phần có thể hình thành bằng việc xác định một
chuẩn tương tác nhằm xúc tiến các giao diện rõ, không mơ hồ. Một thành phần có thể
được cấu trúc với thành phần khác hoặc với phần tử phần mềm khác bằng việc tạo ra
những kết nối lắp ráp hoặc tích hợp theo thứ tự định sẵn.
Mô hình thành phần xác định các cơ chế cho phép để tạo lập các kết nối lắp

ráp hoặc tích hợp thành phần. D’Souza và Wills (1999) quan sát thấy “cắm là tương
thích” chỉ đúng nếu một thành phần đảm bảo kỳ vọng liên kết được với thành phần
khác. Quá trình lắp ráp có thể là khó khăn như nhu cầu đạt mục đích về tính rõ ràng,
chính xác. Chúng ta sử dụng thuật ngữ lắp ráp nhiều phần tử dạng khác nhau trong đó
các thành phần được thảo ra giống như là một gói các mối liên kết động và tĩnh, “cắm
vào là chạy”.


22

Mô hình thành phần có thể xác định các cơ chế cá nhân hoá. Cơ chế đó mô tả
các thành phần có thể mở rộng như thế nào mà không cần sửa chữa. Chúng ta xử lý
việc cá nhân hoá như một dạng tương tác tiên tiến. Một mô hình thành phần cũng có
thể xác định các đặc tính thành phần bắt buộc chẳng hạn như dạng mã hoá, các chuẩn
tài liệu hoặc các giao diện bắt buộc sẽ phải làm.
* Bảng các phần tử cơ sở của một mô hình thành phần
Các chuẩn của các
nhân tố

Mô tả trong chuẩn

Giao diện (Interface)

Đặc tả tính chất và hành vi của thành phần, định nghĩa của
ngôn ngữ định nghĩa giao diện (Interface Decription
Language-IDL)

Tên (Naming)

Các giao diện và các thành phần có tên duy nhất

Siêu dữ liệu

Thông tin về thành phần, giao diện, và mối quan hệ của
chúng

(Meta Data )
Khả năng cùng hoạt
động
(Interoperability)
Tuỳ biến
(Customization )

Giao tiêp và thay đổi dữ liệu giữa các thành phần từ các nhà
cung cấp khác nhau, thực thi với các ngôn ngữ khác nhau
Các giao diện cho các thành phần tùy biến. Các công cụ tùy
biến thân thiện với người dùng sẽ được sử dụng cho những
giao diện này

Composition (tổ hợp/ Các giao diện và các qui tắc kết hợp giữa các thành phần để
kết hợp)
tạo những hệ thống lớn hơn, thêm vào hay thay thế các thành
phần đã tồn tại trong hệ thống
Hỗ trợ tiến hoá
(Evolution Support)

Các quy tắc và các dịch vụ để thay thế các thành phần hoặc
các giao diện bởi các phiên bản mới hơn

Đóng gói và triển

khai (Packaging and
Deployment )

Các tài nguyên và thực thi các gói phần mềm cần thiết cho
việc cài đặt và cấu hình thành phần

Mô hình thành phần là xương sống của một hệ thống hướng thành phần. Nó
cung cấp hỗ trợ quan trọng cho phát triển thành phần, thành phần hoá, liên lạc, phát
triển và tiến hoá. Mô hình thành phần là một yếu tố then chốt nhằm kích hoạt thao tác
giữa các phần, hoàn thiện, bảo trì giống như nhiều thuộc tính chất lượng khác. Hiện
nay, .NET/COM/COM+, CORBA và EJB là 3 mô hình thành phần thương mại chính.


23

1.2.5.2. Thực thi mô hình thành phần
Thực thi mô hình thành phần là một tập chuyên dụng các phần tử phần mềm có
khả năng thực hiện. Nó hỗ trợ các thành phần thực hiện trong cơ chế mô hình thành
phần. Thực thi mô hình thành phần cung cấp:
- Các dịch vụ nền cho phép các thành phần gắn vào mô hình để giao tiếp.
- Các dịch vụ theo chiều ngang, là các dịch vụ độc lập ứng dụng, được sử dụng
bởi các thành phần khác nhau.
Để sử dụng các dịch vụ do mô hình cung cấp, các thành phần cần được triển
khai trong một “bộ chứa”. Đây là một tập của các giao diện được sử dụng để truy cập
các thực thi dịch vụ.
Một hệ điều hành (OS) có chứa phần thực thi mô hình thành phần chỉ gây rắc
rối cho hệ điều hành và làm hạn chế tính khả dụng của mô hình thành phần. Phần thực
thi mô hình thành phần là tầng mỏng điển hình được thực hiện trên đỉnh của một hệ
điều hành. Các hệ điều hành đa nhiệm có thể có tầng cổng đảm bảo tính khả dụng mô
hình thành phần cao nhất.

Chuẩn tương tác trong mô hình thành phần xác định vị trí của một giao diện và
sử dụng các giao diện này theo thứ tự ưu tiên trong thực thi mô hình thành phần. Các
giao diện được xác định bởi một IDL và được đăng ký tại một nơi trung gian trợ giúp
cho thực thi đó. Chuẩn thành phần đối với một mô hình thành phần xác định vị trí
thành phần và thứ tự ưu tiên sử dụng. Nhà cung cấp thực thi mô hình thành phần phải
cung cấp các công cụ như bộ dịch IDL để hỗ trợ cho việc phát triển thành phần.
Thực thi mô hình thành phần có khả năng thực hiện thành phần theo mô hình
thành phần. Có khả năng có nhiều thực thi ứng với một mô hình thành phần.
Hệ điều hành là một trong những hệ thống thành phần thành công đầu tiên
(Szypersky 1997). Hệ điều hành là một chương trình quản lý phần cứng máy tính. Nó
cung cấp nền tảng cho các chương trình ứng dụng, cung cấp các dịch vụ cơ bản như
quản lý bộ nhớ, quản lý file, giao tiếp giữa các quá trình, đồng bộ hóa quy trình và có
chế độ bảo mật.


24

Hệ điều hành là thực thi mô hình thành phần các ứng dụng và được xem là
thành phần thô. Mỗi thực thi mô hình thành phần được phát triển và được tài liệu hóa.
Nhiều nhà cung cấp có thể phát triển các ứng dụng sử dụng các dịch vụ mức thấp được
cung cấp bởi thực thi mô hình thành phần. Tại tâm của ứng dụng, có một thị trường
thành phần chức năng. Chúng ta có thể mua những ứng dụng khác nhau từ các nhà
cung cấp khác nhau và sử dụng chúng cùng nhau trên một máy tính. Tất cả các ứng
dụng đều phải gắn vào chuẩn được xác định bởi một hệ điều hành. Những chuẩn này
là một phần thực thi một hệ điều hành cụ thể, ví dụ như chuẩn UNIX 98 của Linux.
1.2.5.3. Vòng đời phần mềm
Vòng đời phần mềm xây dựng theo hướng thành phần là tiến trình vòng đời cho
một thành phần phần mềm với việc nhấn mạnh các quy tắc nghiệp vụ, mô hình hoá
tiến trình nghiệp vụ, thiết kế, xây dựng, kiểm thử, triển khai, tiến hoá, sử dụng lại
thường xuyên và bảo trì.

Các pha phân tích và thiết kế đối với vòng đời phần mềm xây dựng theo hướng
thành phần dài hơn đáng kể so với vòng đời truyền thống. Ít nhất là một hoạt động
kiểm chứng được chỉ đạo ở cuối mỗi pha trong vòng đời. Đã có nhiều hướng dẫn và
chuẩn được giới thiệu trong kỹ nghệ phần mềm, kiểm chứng là một cái cần thiết tuyệt
đối suốt cả phân tích và thiết kế đảm bảo rằng việc xây dựng và pha kiểm thử đơn vị là
thành công. Trong khi kiểm thử đơn vị thường theo cách bổ sung và kiểm thử thì kiểm
thử dựa trên thành phần lại được thực hiện tách biệt. Các người kiểm thử phần mềm
tham gia theo cách tích hợp tất cả các thành viên của nhóm. Công việc bảo trì thường
được tiến hành hàng năm.
Việc xây dựng thực thi mô hình thành phần yêu cầu các kỹ sư phải có khả năng
tạo lập tốt các cơ sở hạ tầng thành phần phần mềm, hiểu rõ được các mối tương tác
giữa các thành phần để thực hiện đúng các chức năng và hành vi của hệ thống trong
suốt vòng đời.


25

1.2.5.4. S tng th phỏt trin phn mm
Kế hoạch tổng
thể phát triển
phần mềm

Đánh
giá
thành công
của hệ thống
phần mềm

Vấn đề
cần giải

quyết

Đặc tả thực
hiện

Phân rã vấn đề
thành dự án và
các dự án con

Thiết kế cơ
sở hạ tầng
thành phần
logic

Tăng chi tíêt, làm
mịn thiết kế cho
cơ sở hạ tầng
thành phần

Phân tích cơ
sở hạ tầng TP
từ nhiều quan
điểm
Cơ sở hạ tầng thành phần

Chọn mô hình
thành
phần
thích hợp

Thực thi mô hình thành phần

Mô
hình
thành phần

Chú giải:

Mô hình được phân phối
bởi các hãng
hoặc nếu là một mô
hình thành phần riêng
thì phải khả thi

dự án
dự án con
thành phần
tương tác
quan điểm

Hình 1.11. Sơ đồ tổng thể
phát triển phần mềm