TRƯỜNG ĐẠI HỌC KINH TẾ QUỐC DÂN
----------

PHẠM THỊ HẰNG

HOÀN THIỆN QUY TRÌNH SẢN XUẤT PHẦN MỀM
TẠI TRUNG TÂM NGHIÊN CỨU
CÔNG NGHỆ MẠNG VIETTEL

CHUYÊN NGÀNH: HỆ THỐNG THÔNG TIN QUẢN LÝ

LUẬN VĂN THẠC SĨ KINH DOANH VÀ QUẢN LÝ

NGƯỜI HƯỚNG DẪN KHOA HỌC: TS. TRƯƠNG VĂN TÚ

HÀ NỘI – 2015


LỜI CAM ĐOAN

Tác giả xin cam đoan luận văn này là công trình nghiên cứu khoa học độc lập
của tác giả. Các tài liệu, tư liệu được sử dụng trong luận văn có nguồn gốc rõ ràng,
các kết quả nghiên cứu là quá trình lao động trung thực của tác giả.

Hà Nội, ngày

tháng

năm 2015

TÁC GIẢ LUẬN VĂN

Phạm Thị Hằng


LỜI CẢM ƠN

Em xin gửi lời cảm ơn sâu sắc tới: Trường Đại học Kinh tế quốc dân, Viện
Đào tạo sau Đại học Trường Đại học Kinh tế quốc dân, Khoa hệ thống thông tin
quản lý Trường Đại học Kinh tế quốc dân, Trung tâm Nghiên cứu công nghệ mạng
Viettel đã tạo điều kiện giúp đỡ để tôi hoàn thành luận văn này.
Em xin chân thành cảm ơn TS. Trương Văn Tú đã trực tiếp hướng dẫn, tận
tình chỉ bảo, giúp đỡ tôi trong suốt quá trình thực hiện luận văn. Thầy đã giúp em có
khả năng tổng hợp những tri thức khoa học, những kiến thức thực tiễn quản lý và
phương pháp nghiên cứu khoa học. Thầy đã góp ý, chỉ bảo trong việc định hướng
và hoàn thiện luận văn.
Em xin cảm ơn các thầy, cô giáo tại Trường Đại học Kinh tế quốc dân đã
giúp đỡ, góp ý, động viên em trong suốt quá trình học tập và nghiên cứu.
Xin trân trọng cảm ơn./.
Hà Nội, ngày

tháng

năm 2015

TÁC GIẢ LUẬN VĂN

Phạm Thị Hằng


MỤC LỤC

LỜI CAM ĐOAN
LỜI CẢM ƠN
MỤC LỤC
DANH MỤC CÁC KÝ HIỆU, CÁC CHỮ VIẾT TẮT
DANH MỤC HÌNH, BẢNG, BIỂU ĐỒ
PHẦN MỞ ĐẦU.........................................................................................................1
CHƯƠNG 1: CƠ SỞ PHƯƠNG PHÁP LUẬN VỀ QUY TRÌNH SẢN XUẤT
PHẦN MỀM................................................................................................................ 5
1.1. Khái niệm và sự cần thiết của quy trình phát triển phần mềm.....................5
1.1.1.Khái niệm chung về phần mềm....................................................................5
1.1.2. Khái niệm quy trình sản xuất phần mềm.....................................................5
1.1.3. Tầm quan trọng của quy trình sản xuất phần mềm......................................6
1.2. Một số quy trình sản xuất phần mềm hiện nay...............................................6
1.2.1. Quy trình sản xuất phần mềm truyền thống (mô hình thác nước)...............6
1.2.2. Một số các mô hình khác..........................................................................11
1.2.3. Mô hình Agile...........................................................................................17
CHƯƠNG 2: THỰC TRẠNG ÁP DỤNG QUY TRÌNH SẢN XUẤT PHẦN
MỀM TẠI TRUNG TÂM NGHIÊN CỨU CÔNG NGHỆ MẠNG VIETTEL.....32
2.1. Tổng quan về Trung tâm Nghiên cứu công nghệ mạng Viettel....................32
2.1.1. Giới thiệu chung.......................................................................................32
2.1.2. Cơ cấu tổ chức của Trung tâm.................................................................35
2.2. Phân tích thực trạng áp dụng quy trình sản xuất phần mềm tại Trung
tâm Nghiên cứu công nghệ mạngViettel...............................................................53
2.2.1. Thực trạng áp dụng quy trình sản xuất phần mềm tại Trung tâm..............53
2.2.2. Một số bất cập trong quá trình triển khai..................................................66
2.3. Hiện trạng công cụ hiện đang sử dụng tại Trung tâm để quản lý quy
trình phát triển dự án phần mềm tại VTTEK.....................................................68
2.3.1. Ưu, nhược điểm của các công cụ hiện đang sử dụng................................68



2.3.2. Giới thiệu về công cụ quản lý sản xuất Rational Team Concert (RTC).....70
CHƯƠNG 3: ĐỀ XUÁT GIẢI PHÁP NHẰM HOÀN THIỆN QUY TRÌNH
SẢN XUẤT PHẦN MỀM TẠI VTTEK, ỨNG DỤNG QUẢN LÝ DỰ ÁN
TRÊN CÔNG CỤ RTC_IBM..................................................................................80
3.1. Đề xuất giải pháp hoàn thiện quy trình sản xuất phần mềm.......................80
3.1.1. Luồng quy trình thực hiện.........................................................................80
3.1.2. Nội dung chi tiết các bước thực hiện quy trình.........................................80
3.1.3. Đánh giá hiệu quả khi sử dụng quy trình mới so với quy trình cũ............86
3.2. Ứng dụng quản lý dự án sản xuất phần mềm theo quy trình mới trên
công cụ quản lý sản xuất RTC_IBM.....................................................................92
3.2.1. Các bước thao tác thực hiện theo quy trình trên công cụ RTC_IBM........92
3.2.2. Một số báo cáo đầu ra khi quản lý dự án theo quy trình mới..................100
KẾT LUẬN.............................................................................................................. 103
DANH MỤC TÀI LIỆU THAM KHẢO..................................................................104


DANH MỤC CÁC KÝ HIỆU, CÁC CHỮ VIẾT TẮT

KÝ HIỆU
TDD
BDD
XP
PO
SM
SXKD
BGĐ
IT
GSM
LTE
UMTS

QTDA
CBGP
ULNL
CB QLCH
P.KTCN
KHDA
KHCT
BBH
TT KTCNTT
VHKT
CBPT
HDCD
HDVH
HDKT
ATTT
BBNTNB
CSKH
CBTK

GIẢI THÍCH
Test-Driven Development
Behavior-Driven Development
eXtreme Programming
Product Owner
Scrum Master
Sản xuất kinh doanh
Ban Giám đốc
Information technology
Global System for Mobile Communications
Long Term Evolution

Universal Mobile Telecommunications Service
Quản trị dự án
Cán bộ giải pháp
Ước lượng nỗ lực
Cán bộ Quản lý cấu hình
Phòng Kỹ thuật công nghệ
Kế hoạch dự án
Kế hoạch chi tiết
Biên bản họp
Trung tâm khai thác công nghệ thông tin
Vận hành khai thác
Cán bộ phát triển
Hướng dẫn cài đặt
Hướng dẫn vận hành
Hướng dẫn khai thác
An toàn thông tin
Biên bản nghiệm thu nội bộ
Chăm sóc khách hàng
Cán bộ triển khai


Testcase
SVN
QLSX
TB
VTT
CMR
TIMORE
VTN
LBS

TKTT
TKCT
RTC
RRC
RQM
GUI
CSDL

Kịch bản kiểm thử
Subversion
Quản lý sản xuất
Trung bình
Tổng công ty viễn thông viettel
Cameroon
Dongtimore
Tổng công ty mạng lưới viettel
Location base system
Thiết kế tổng thể
Thiết kế chi tiết
Rational Team Concert
Rational Requirement Compose
Rational Quanlity Management
Graphical User Interface
Cơ sở dữ liệu


DANH MỤC HÌNH, BẢNG, BIỂU ĐỒ
HÌNH:
Hình 1.1:


Mô hình thác nước ..............................................................................7

Hình 1.2:

Mô hình nguyên mẫu ........................................................................11

Hình 1.3:

Mô hình phát triển nhanh ..................................................................13

Hình 1.4:

Mô hình xoắn ốc............................................................................... 16

Hình 1.5:

Tỉ lệ phương pháp Agile được dùng trên thế giới .............................23

Hình 1.6:

Phương pháp Scrum ..........................................................................25

Hình 2.1:

Mô hình tổ chức của Trung tâm VTTEK.......................................... 35

Hình 2.2:

Mô hình SVN.................................................................................. 69


Hình 2.3:

Mối quan hệ giữa 3 thành phần trong hệ thống RTC ........................71

Hình 2.4:

Mối quan hệ giữa các đối tượng trên RTC....................................... 72

Hình 2.5:

Mô hình quản lý source code............................................................ 73

Hình 2.6:

Mối quan hệ giữa các đối tượng trên hệ thống RRC .........................75

Hình 2.7:

Mối quan hệ giữa các đối tượng trên hệ thống RQM........................ 77

BẢNG:
Bảng 3.1.

Tỷ lệ lỗi phát triển lũy kế của các dự án qua các tháng..................... 88

Bảng 3.2.

Tỉ lệ lỗi và chi phí khắc phục tháng 06/2015 ...................................90

Bảng 3.3.


Số liệu lỗi triển khai khách hàng qua các năm ..................................92

BIỂU ĐỒ:
Biểu đồ 3.1. Biểu đồ tỷ lệ lỗi phát triển ................................................................88


1

PHẦN MỞ ĐẦU
1. Tính cấp thiết của đề tài
Khi công nghệ thông tin ngày càng phát triển thì sự cạnh tranh trong lĩnh vực
này ngày càng trở nên khắc nghiệt. Thực tế đó là cơ hội nhưng cũng chính là những
thách thức với bất kì doanh nghiệp nào theo đuổi lĩnh vực công nghệ thông tin.
Trong cuộc chiến đấu sinh tồn đó chỉ có những doanh nghiệp đưa ra được sản phẩm
nhanh, chất lượng và thỏa mãn nhu cầu khách hàng mới có thể tồn tại. Vậy làm thế
nào để có thể có được một phần mềm đáp ứng được nhu cầu khách hàng một cách
nhanh nhất? Chúng ta viết ra càng nhiều phần mềm thì sự đòi hỏi, yêu cầu của con
người càng nhiều. Chính vì vậy, những nhà quản lý và phát triển phần mềm tiếp tục
tìm kiếm phương thức phát triển phần mềm tốt hơn. So với 30 năm trước chúng ta
đã có những chiếc máy tính rẻ hơn, nhanh hơn, nhiều ngôn ngữ lập trình mạnh mẽ
ra đời, số lượng nhiều hơn cần thiết những công cụ hỗ trợ, sự đào tạo tốt hơn và có
những hiểu biết sâu hơn về lý thuyết phần mềm. Internet đã thay đổi cách con người
giao tiếp với nhau, thúc đẩy sự trao đổi thông tin và thay đổi một cách triệt để sự kỳ
vọng của con người về cách thức phần mềm làm việc. Chúng ta cũng có số lượng
đáng kể những phương pháp khác nhau giúp xác định con đường phát triển phần
mềm tốt nhất và đó chính là khía cạnh của việc tìm ra một quy trình phát triển phần
mềm phù hợp nhất. Quy trình hỗ trợ cho mọi thành viên trong dự án từ người cũ
đến người mới, trong hay ngoài công ty đều có thể xử lý đồng bộ công việc tương
ứng vị trí của mình thông qua cách thức chung của công ty, hay ít nhất ở cấp độ dự

án. Có thể nói qui trình phát triển/xây dựng phần mềm có tính chất quyết định để
tạo ra sản phẩm chất luợng tốt với chi phí thấp và năng suất cao.
Việc cải tiến các mô hình phát triển phần mềm luôn là đề tài nghiên cứu hấp
dẫn, với sự tham gia tích cực không những từ các nhà sản xuất phần mềm mà còn từ
các viện đại học khắp thế giới. Riêng với các nhà phát triển phần mềm, họ luôn cố
gắng cải tiến liên tục qui trình phát triển của mình nhằm không ngừng đổi mới,
nâng cao năng suất và chất lượng sản phẩm. Tuy nhiên, một điều dễ thấy là việc lựa


2

chọn, tùy biến mô hình phù hợp cho các dự án đã khó, nhưng việc vận hành nó vào
trong quá trình phát triển sản phẩm càng khó hơn.
Là một trong những doanh nghiệp nằm trong guồng xoáy của lĩnh vực công
nghệ thông tin, Trung tâm Nghiên cứu công nghệ mạng Viettel (VTTEK) luôn đặt
mục tiêu đưa ra các sản phẩm tốt nhất, đảm bảo chất lượng, thỏa mãn nhu cầu của
khách hàng, làm chủ hoàn toàn phầm mềm và phần cứng. Với mục tiêu đó, Ban
Giám đốc Trung tâm luôn luôn coi trọng việc sản xuất sản phẩm theo quy trình nhất
định, kiểm soát ngay từ giai đoạn đầu vào của sản phẩm, đảm bảo không có bất kì
sai sót nào trong quá trình sản xuất, hạn chế tối đa các lỗi lọt sau triển khai cho
khách hàng, nâng cao uy tín của Trung tâm trên thị trường trong nước và thế giới.
Sản phẩm của Trung tâm chủ yếu là các phần mềm lõi viễn thông như PSCore
(Package swiching core_ Hệ thống chuyển mạch gói), OCS (Online Charging
System_ Hệ thống tính cước online), MSS (Mobile Softswich_Hệ thống chuyển
mạch mềm)… với đặc thù là các sản phẩm nghiên cứu: yêu cầu thay đổi liên tục,
chưa có một hướng đi rõ ràng, chưa nhìn được hết tính năng của sản phẩm…Chính
vì đặc trưng này mà quy trình sản xuất hiện tại dựa trên ý tưởng của mô hình thác
nước với các giai đoạn, chức năng rõ ràng đã xuất hiện nhiều hạn chế, điển hình
như năm 2013 có 4/5 dự án không hoàn thành kế hoạch sản xuất kinh doanh năm,
năm 2014 có 4/12 dự án không hoàn thành kế hoạch.

Trước tình hình đó, việc tìm ra được một quy trình phù hợp với các dự án
nghiên cứu trở nên vô cùng quan trọng nhằm nâng cao chất lượng sản phẩm, làm
chủ hoàn toàn thiết bị mạng viễn thông, đáp ứng nhu cầu khách hàng với phương
châm phục vụ mỗi khách hàng như một cá thể riêng biệt.
Xuất phát từ đòi hỏi của thực tiễn, tác giả đã chọn đề tài “Hoàn thiện quy
trình sản xuất phần mềm tại Trung tâm Nghiên cứu công nghệ mạng Viettel”

2. Mục đích nghiên cứu
Mục đích nghiên cứu đề tài luận văn bao gồm:
- Hệ thống hoá những vấn đề thuộc cơ sở lý thuyết liên quan tới quy trình phát
triển phầm mềm.
- Nghiên cứu và hoàn thiện quy trình sản xuất phần mềm tại Trung tâm
Nghiên cứu phát triển thiết bị mạng viễn thông Viettel.


3

- Vận dụng quy trình vào thực tế các dự án tại Trung tâm Nghiên cứu công
nghệ mạng Viettel.
Quy trình sản xuất phần mềm đáp ứng được các mục tiêu cụ thể sau đây:
- Phù hợp với đặc trưng của các dự án nghiên cứu
- Quản lý, đánh giá được hiệu quả nguồn lực của các dự án, của từng cá nhân,
của cả Trung tâm
- Có một cái nhìn tổng quan về tiến độ, chất lượng, kế hoạch của dự án.
- Rút ngắn thời gian báo cáo, hỗ trợ cho Ban Giám đốc và lãnh đạo phòng
trong việc quản lý dự án.
- Quản lý các vấn đề của dự án, đưa ra những cảnh báo, biện pháp khắc phục
kịp thời.

3. Đối tượng và phạm vi nghiên cứu

3.1. Đối tượng nghiên cứu của đề tài
Đối tượng nghiên cứu của đề tài là quy trình phát triển phần mềm của Trung
tâm Nghiên cứu công nghệ mạng Viettel.

3.2. Phạm vị nghiên cứu của đề tài
Phạm vi nghiên cứu của đề tài là quy trình sản xuất của các dự án nghiên cứu
tại Trung tâm Nghiên cứu công nghệ mạng Viettel trên cơ sở tổng kết, đánh giá các
hạn chế trong quá trình thực hiện dự án theo quy trình dựa trên mô hình thác nước.

4. Phương pháp nghiên cứu
Trong quá trình nghiên cứu, tác giả sử dụng các phương pháp sau:
- Phương pháp tiếp cận hệ thống đi từ tổng thể đến chi tiết, xem xét quy trình
dự án như một chỉnh thể thống nhất bắt đầu từ giai đoạn khảo sát, khởi động dự án,
xác định các yêu cầu của khách hàng, danh sách tính năng của sản phẩm.
- Phương pháp nghiên cứu định tính, định lượng.
- Các phương pháp chuyên dụng của tin học kinh tế, các bước trong quy trình
sản xuất phần mềm theo mô hình thác nước.
Các phương pháp thu thập dữ liệu được sử dụng trong luận văn:
- Luận văn sử dụng các phương pháp nghiên cứu như phương pháp tổng hợp,

phân tích và thống kê để tìm kiếm các dữ liệu thứ cấp có liên quan đến các bước
thực hiện khi phát triển 1 phần mềm, nhu cầu các thông tin trong quan lý dự án tại


4

Trung tâm Nghiên cứu công nghệ mạng Viettel.
- Luận văn sử dụng các phương pháp thu thập dữ liệu như: Phỏng vấn sâu,
thu thập thông tin từ các thành viên của dự án trong quá trình thực hiện thực tế,
phương pháp quan sát, phương pháp nghiên cứu tài liệu có liên quan đến quy trình,

các yêu cầu khi phát triển sản phẩm.

5. Kết quả đạt được của đề tài
Luận văn dự kiến sẽ đạt được các kết quả chính sau:
[1] Hoàn thiện quy trình sản xuất phần mềm tại Trung tâm Nghiên cứu phát
triển thiết bị mạng viễn thông Viettel.
[2] Ứng dụng quản lý dự án theo quy trình đề xuất trên công cụ quản lý dự án
RTC_IBM

6. Đóng góp của luận văn
Đề tài dự kiến có những đóng góp cơ bản sau đây:
- Tổng quát hoá cơ sở phương pháp luận về quy trình sản xuất phần mềm.
- Khảo sát và phân tích thực trạng áp dụng quy trình sản xuất phần mềm tại
Trung tâm Nghiên cứu công nghệ mạng Viettel.
- Đề xuất giải pháp hoàn thiện quy trình sản xuất phần mềm tại Trung tâm
Nghiên cứu công nghệ mạng Viettel.
- Ứng dụng quy trình mới đề xuất vào thực tế, áp dụng quản lý dự án trên công
cụ quản lý sản xuất RTC-IBM.

7. Kết cấu của luận văn
Ngoài phần mở đầu, kết luận, mục lục, danh mục viết tắt, danh mục bảng biểu,
danh mục hình vẽ, danh mục tài liệu tham khảo, phụ lục, nội dung của luận văn
được kết cấu gồm 3 chương:
Chương 1: Cơ sở phương pháp luận về quy trình sản xuất phần mềm.
Chương 2: Thực trạng áp dụng quy trình sản xuất phần mềm tại Trung tâm
Nghiên cứu công nghệ mạng Viettel.
Chương 3: Đề xuất giải pháp nhằm hoàn thiện quy trình sản xuất phần mềm
tại VTTEK, ứng dụng quản lý dự án trên công cụ RTC-IBM



5

CHƯƠNG 1
CƠ SỞ PHƯƠNG PHÁP LUẬN VỀ
QUY TRÌNH SẢN XUẤT PHẦN MỀM

1.1. Khái niệm và sự cần thiết của quy trình phát triển phần mềm
1.1.1.Khái niệm chung về phần mềm
Kể từ năm 1950 đến nay, phần mềm đã phát triển qua nhiều công đoạn
theo xu hướng quy mô ngày càng thu nhỏ nhưng tính năng ngày càng được
nâng cao. Cùng với sự phát triển của phần cứng, tính chất thương mại hóa của
phần mềm ngày bộc lộ rõ và đỉnh cao nhất là việc sản xuất phần mềm ở quy mô
đại trà, tác phong công nghiệp.
Trong quy mô học đường, phần mềm được đồng nhất với khái niệm chương
trình máy tính. Nhưng khi sản xuất phần mềm trở thành một ngành có vị trí đáng kể
trong nền kinh tế quốc dân thì khái niệm phần mềm đã hoàn chỉnh hơn, tổng quát
hơn. Sản xuất phần mềm với cách hiểu là công nghệ phần mềm. Trong công nghệ
phần mềm, người ta chấp nhận định nghĩa của nhà tin học người Mỹ Roger
Pressman. Định nghĩa này nói rằng: phần mềm trong công nghệ phần mềm được
hiểu là một tập hợp gồm 3 yếu tố:
- Các chương trình máy tính
- Các cấu trúc dữ liệu
- Hệ thống tài liệu hướng dẫn sử dụng.

1.1.2. Khái niệm quy trình sản xuất 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. Hầu hết các thao tác này được tiến hành bởi các kỹ sư phần mềm.
Các hoạt động cơ bản của phát triển phần mềm:



6

- Đặ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.
- Cài đặt phần mềm: để phần mềm đạt được những yêu cầu trong đặc tả thì
phải có quá trình cài đặt.
- Đá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.1.3. Tầm quan trọng của quy trình sản xuất phần mềm
Quy trình sản xuất phần mềm nhằm hỗ trợ và nâng cao chất lượng, hạn chế rủi
ro cho sản phẩm phần mềm làm ra.
Quy trình là nền tảng của công nghệ phần mềm, nó là chất kết dính công nghệ
và cho phép phát triển các phần mềm hiệu quả và đúng thời hạn.

1.2. Một số quy trình sản xuất phần mềm hiện nay.
1.2.1. Quy trình sản xuất phần mềm truyền thống (mô hình thác nước)
1.2.1.1. Đặc điểm
Các phương pháp truyền thống là các phương pháp thiên về kế hoạch, quá
trình phát triển phần mềm phải tuân theo một quy trình nghiêm ngặt. Trong quá
trình phát triển phần mềm, rất nhiều tài liệu được tạo ra, được xét duyệt và đó là
một yếu tố quan trọng trong quản lý rủi ro.
Toàn bộ quá trình phát triển thường được lên kế hoạch chi tiết và các tài liệu
trước cũng như trong quá trình phát triển được chuẩn bị đầy đủ. Quá trình phát triển
được thực hiện theo quy trình được định trước, và việc tuân thủ quy trình sẽ làm
tăng chất lượng phần mềm và giảm rủi ro.
Quá trình sản xuất phần mềm giống như sản xuất các mặt hàng công nghiệp

khác. Những người phát triển thực hiện công việc một cách nghiêm ngặt theo các


7

chuẩn và các quy trình, không yêu cầu sáng tạo nhiều. Những người quản lý chỉ cần
tăng năng lực sản xuất và đạt được các mục tiêu như sau:
 Giảm thiểu lỗi và các công việc được diễn ra theo đúng kế hoạch.
 Giữ ổn định về tổ chức, sản lượng,…
 Chuẩn hóa mọi thao tác và buộc mọi thành viên trong dự án tuân theo
một cách nghiêm ngặt.
 Không cho phép mắc sai lầm.

1.2.1.2. Mô hình thác nước (Watterfall)
* Nội dung mô hình:

Hình 1.1: Mô hình thác nước

Nghiên cứu lập kế hoạch dự án: Mục đích của giai đoạn này là nghiên cứu,
đề xuất giải pháp kỹ thuật, tiến hành xây dựng hợp đồng với khách hàng, theo dõi
tiến trình thực hiện hợp đồng, tổ chức thanh toán thanh lý hợp đồng và lập kế hoạch
tổng quát về dự án, dự trù kinh phí cũng như thời gian thực hiện.
Phân tích yêu cầu phần mềm: Tiến trình thu thập yêu cầu được tập trung và
làm mạnh đặc biệt vào phần mềm. Để hiểu được bản chất của các chương trình phải
xây dựng, kỹ sư phần mềm phải hiểu về lĩnh vực thông tin đối với phần mềm cũng
như các chức năng cần có, hiệu năng và giao diện của phần mềm


8


Thiết kế: Thiết kế phần mềm là một tiến trình nhiều bước tập trung vào bốn
thuộc tính phân biệt của chương trình là:
Cấu trúc dữ liệu
Kiến trúc phần mềm
Các thủ tục
Các đặc trưng giao diện
Tiến trình thiết kế dịch các yêu cầu thành một biểu diễn của phần mềm có thể
được khẳng định về chất lượng trước khi giai đoạn mã hóa bắt đầu. Giống như các
yêu cầu, việc thiết kế phải được lập tư liệu và trở thành một bộ phận của cấu hình
phần mềm.
Mã hóa và kiểm thử đơn vị: Thiết kế phải được dịch thành ngôn ngữ máy mà
máy tính có thể đọc và hiểu được. Bước mã hóa thực hiện công việc này. Nếu thiết
kế được thực hiện theo một cách chi tiết thì việc mã hóa có thể được thực hiện một
cách máy móc. Khái niệm mã hóa ở đây khác với khái niệm mã hóa thông tin thành
các ký hiệu để phân biệt các đối tượng
Kiểm thử: Tiến trình kiểm thử tập trung vào phần logic bên trong của phần
mềm, đảm bảo rằng tất cả các câu lệnh đều được kiểm tra nhằm phát hiện ra các lỗi
và cho kết quả phù hợp với dữ liệu kiểm thử đưa vào
Vận hành (triển khai): Đây là công đoạn tiếp sau công đoạn test, sau khi có
được phần mềm đóng gói sẽ tiến hành triển khai lắp đặt và hướng dẫn sử dụng cho
khách hàng. Nhiều người dùng vẫn coi triển khai là một phần việc tất yếu đi kèm
khi chuyển giao phần mềm, nên khi đánh giá thường chỉ quan tâm tới các chức năng
và tính năng của hệ thống mà quên một điều quan trọng rằng đó là những tiềm năng
sẵn có trong hệ thống. Để đưa hệ thống cùng toàn bộ tính năng ưu việt của nó vào
ứng dụng trong thực tế thì chỉ có quá trình triển khai tốt mới có thể biến các tiềm
năng đó thành hiện thực. Đào tạo người sử dụng là một hoạt động không thể thiếu
trong quá trình triển khai bất kỳ một phần mềm nào. Mục tiêu của công tác này là
người dùng được đào tạo để điều hành hệ thống mới, thông báo một số tình huống



9

có thể gặp lỗi khi vận hành sản phẩm để người dùng biết cách xử trí. Đào tạo không
chỉ bao gồm các hoạt động nhập dữ liệu, lập báo cáo mà còn phải giúp người dùng
hiểu được cách thức vận hành của phần mềm.
Bảo trì: Sau khi bàn giao phần mềm cho khách hàng, chắc chắn nó sẽ phải có
những thay đổi để hoàn toàn tương thích với các điều kiện quản lý của cơ sở thực tế
(Sự thay đổi của hệ điều hành, hay thiết bị ngoại vi). Quá trình bảo trì còn xảy ra
khi khách hàng yêu cầu nâng cao chức năng hay hiệu năng. Việc bảo trì phần mềm
phải áp dụng lại các bước của dòng đời phát triển nói trên cho chương trình hiện tại
chứ không phải là chương trình mới. Sự thay đổi có thể chỉ là sửa lỗi lập trình,
nhưng cũng có thể cần thay đổi lại thiết kế hệ thống. Có 4 hoạt động trong giai đoạn
bảo trì bao gồm: bảo trì hiệu chỉnh, bảo trì tiếp hợp, bảo trì hoàn thiện, bảo trì
phòng ngừa. Công nghệ bảo trì đưa ra chìa khóa để cải tiến năng suất bảo trì. Với
những thiết kế cẩn thận, sự cung cấp tài liệu kỹ lưỡng và một loạt các phương pháp
kiểm tra hoàn thiện, các lỗi sẽ dễ dàng được chẩn đoán và hiệu chỉnh khi chúng xảy
ra, phần mềm sẽ dễ sửa. Thời gian chi phí cho mỗi yêu cầu bảo trì sẽ ít hơn.
* Ưu điểm:
Dễ phân công công việc, phân bố chi phí, giám sát công việc.
Kiến trúc hệ thống hàng đợi ổn định.
Các giai đoạn được định nghĩa, với đầu vào và đầu ra rõ ràng. Mô hình này cơ
bản dựa trên tài liệu nhất là trong các giai đoạn đầu, đầu vào và đầu ra đều là tài
liệu.
Sản phẩm phần mềm được hình thành thông qua chuỗi các hoạt động xây
dựng phần mềm theo trình tự rõ ràng.
* Nhược điểm:
Các dự án trong thực tế hiếm khi tuân theo dòng chảy tuần tự mà mô hình đề
nghị. Mặc dầu mô hình cho phép lặp, nhưng điều đó chỉ làm gián tiếp. Kết quả là
những thay đổi có thể gây ra lẫn lộn khi nhóm phát triển làm việc.



10

Khách hàng thường khó phát biểu mọi yêu cầu một cách tường minh ngay từ
đầu. Mô hình tuần tự tuyến tính đòi hỏi điều này và thường khó thích hợp với sự
không chắc chắn tự nhiên tồn tại vào lúc đầu của nhiều dự án. Khách hàng phải
kiên nhẫn chờ đợi, vì bản làm việc được của chương tình chỉ có được vào cuối của
thời gian dự án. Một sai lầm ngớ ngẩn, nếu đến lúc có chương trình làm việc mới
phát hiện ra, có thể là một thảm họa.
Chỉ tiếp xúc với khách hàng ở pha đầu tiên nên phần mềm không đáp ứng
được hết các yêu cầu của khách hàng.
Chi phí phát triển dự án tương đối lớn
Khả năng thất bại cao.
Với việc phân tích một số dự án hiện tại, Bradax thấy rằng bản chất tuyến tính
của vòng đời cổ điển dẫn tới "các trạng thái tắc nghẽn", nghĩa là có một số thành
viên của nhóm phát triển phải chờ đợi sự chuyển giao từ nhóm khác hoàn thành
công việc ở pha trước. Trong thực tế, thời gian chờ đợi có thể vượt quá thời gian sản
xuất. Trạng thái nghẽn có xu hướng xẩy ra vào thời gian đầu và cuối của quy trình
phần mềm.
* Ứng dụng:
Yêu cầu được định nghĩa rất rõ ràng, chi tiết và hầu như không thay đổi,
thường xuất phát từ sản phẩm đã đạt mức ổn định
Yêu cầu mới bổ sung (nếu có) cũng sớm được xác định rõ ràng, đầy đủ từ đầu
dự án.
Đội ngũ thực hiện quen thuộc và hiểu rõ tất cả yêu cầu của dự án, và có nhiều
kinh nghiệm với các công nghệ được dùng để phát triển sản phẩm.
Dự án được xác định hầu như không có rủi ro.


11


1.2.2. Một số các mô hình khác
1.2.2.1. Mô hình nguyên mẫu (Prototyping model)
* Nội dung mô hình :
Mô hình làm bản mẫu (hình dưới) bắt đầu với việc thu thập yêu cầu. Người
phát triển và khách hàng gặp nhau và xác định các 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, và miền nào bắt buộc phải xác định 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 mềm thấy được đối với người dùng (như cách đưa vào và định dạng đưa ra).
Thiết kế nhanh dẫn tới việc xây dựng một bản mẫu. Bản mẫu được khách hàng /
người dùng đánh giá và được dùng để làm mịn các yêu cầu đối với phần mềm cần
phát triển. 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
nhu cầu của khách hàng trong khi đồng thời lại làm cho người phát triển hiểu được
kĩ hơn cần phải thực hiện nhu cầu nào

Vi chỉnh yêu
cầu

Hình 1.2: Mô hình nguyên mẫu


12

* Ưu điểm:
Người sử dụng sớm hình dung ra chức năng và đặc điểm của hệ thống.
Cải thiện sự liên lạc giữa nhà phát triển và người sử dụng.
* Nhược điểm:
Khi mẫu (prototype) không chuyển tải hết các chức năng, đặc điểm của hệ
thống phần mềm thì người sử dụng có thể thất vọng và mất đi sự quan tâm đến hệ
thống sẽ được phát triển.

Prototype thường được làm nhanh, thậm chí vội vàng, theo kiểu "hiện thực sửa" và có thể thiếu sự phân tích đánh giá một cách cẩn thận tất cả khía cạnh liên
quan đến hệ thống cuối cùng.
Nói chung mô hình này vẫn chưa thể cải thiện được việc loại trừ khoảng cách
giữa yêu cầu và ứng dụng cuối cùng.
* Ứng dụng:
Hệ thống chủ yếu dựa trên giao diện người dùng (GUI)
Khách hàng, nhất là người sử dụng cuối, không thể xác định rõ ràng yêu cầu.

1.2.2.2. Mô hình phát triển nhanh (RAD model)
* Nội dung mô hình:
Mô hình này được đưa ra bởi IBM vào những năm 1980, chu kì phát triển
ngắn (60-90 ngày). Để đạt được mục tiêu này, RAD dựa trên phương pháp phát
triển trên cơ sở thành phần hoá hệ thống cùng với việc tái sử dụng các thành phần
thích hợp. RAD thích hợp cho những hệ thống quản lý thông tin. Phần lớn RAD dựa vào phương pháp luận mà người phân tích sử dụng các kỹ thuật đặc biệt và
công cụ máy tính để tăng tốc các giai đoạn phân tích, thiết kế, và thực hiện, như
công cụ CASE (computer-aided software engineering). Nhược điểm của phương
pháp này: Người phát triển phải có kỹ năng và được huấn luyện tốt cho việc sử
dụng công cụ cho việc phát triển nhanh; hệ thống có khả năng phân tách module rõ
ràng, người phát triển và khách hàng cần phải nỗ lực cộng tác.


13

Hình 1.3: Mô hình phát triển nhanh

* Ưu điểm:
Cho phép giảm thời gian phát triển các ứng dụng CSDL và có nhiều giao diện
người dùng hay tích hợp các thành phần có sẵn.
Người sử dụng sẽ tham gia vào các hoạt động kiểm thử.
* Nhược điểm:

Khó có sự nhất quán giữa những thành phần được phát triển bởi các nhóm
khác nhau.
Không phù hợp cho những ứng dụng đòi hỏi hiệu suất vì thường phụ thuộc
vào sự hỗ trợ của môi trường phát triển và ngôn ngữ cấp cao.
* Ứng dụng:
Hệ thống quản lý thông tin kiểu những ứng dụng dựa trên GUI và CSDL.
Có sự hỗ trợ của công cụ hay sử dụng ngôn ngữ cấp cao.
Hệ thống không yêu cầu khắt khe về hiệu suất.

1.2.2.3. Mô hình tăng trưởng (Incremental model)
* Nội dung mô hình:
Thay vì chuyển giao một lần, quá trình phát triển và chuyển giao được chia
làm nhiều lần, mỗi chuyển giao đáp ứng một phần chức năng. Yêu cầu người dùng


14

được phân loại ưu tiên, mức cao sẽ thuộc phần chuyển giao sớm. Khi phát triển một
bản tăng, yêu cầu tương ứng là cố định, tuy nhiên, yêu cầu cho bản tăng sau vẫn
phát triển.
* Ưu điểm:
Giảm rủi ro sớm trong chu kỳ phát triển phần mềm. Những yêu cầu quan trọng
thường được phát triển và chuyển đến người sử dụng sớm.
Phản hồi của nguời sử dụng về những vấn đề phát sinh trong phiên bản trước
được dùng để cải tiến và ngăn ngừa những vấn đề tương tự xảy ra trong những
phiên bản tiếp theo.
* Nhược điểm:
Tổng chi phí lập kế hoạch phát triển cho toàn hệ thống có thể cao hơn. Lưu ý,
ở đây chỉ đề cập chi phí lập kế hoạch ban đầu, không bao gồm tất cả chi phí phát
sinh. Trong thực tế, nếu ứng dụng hợp lý, toàn bộ chi phí và thời gian cho đến khi

sản phẩm được nghiệm thu có thể thấp hơn so với mô hình khác.
Các yêu cầu về kế hoạch và hoạt động trong qui trình cụ thể sẽ phức tạp hơn.
* Ứng dụng:
Mô hình lặp:
Đội ngũ phát triển quen thuộc với lĩnh vực dự án nhưng không có nhiều kinh
nghiệm, nhất là về công nghệ được dùng phát triển dự án.
Có nhiều rủi ro về mặt kỹ thuật
Mô hình tăng dần:
Rủi ro được phân tích và xác định ngay từ đầu.
Giao tiếp giữa các module cũng được xác định rõ ràng từ đầu.
Đội ngũ phát triển quen thuộc với lĩnh vực của dự án và có nhiều kinh nghiệm.
Hệ thống lớn được phát triển trong thời gian dài, khách hàng cần triển khai
sớm một số phần của hệ thống.


15

1.2.2.4. Mô hình xoắn ốc (Spiral model)
* Nội dung mô hình:
Ban đầu do Boehm đề xuất, là mô hình phát triển từ mô hình thác nước cho
thấy mức độ tổng quát hơn của các pha sản xuất của một sản phẩm. Mô hình này có
thể chỉ ra các rủi ro có thể hình thành trên căn bản của mô hình quá trình (sản xuất)
tổng quát. Mô hình Boehm có dạng xoắn ốc. Mỗi vòng lặp đại diện cho một pha của
quá trình phần mềm. Vòng trong cùng tập trung về tính khả thi, vòng kế lo về định
nghĩa các yêu cầu, kế đến là thiết kế,… Không có một pha nào được xem là cố định
trong vòng xoắn. Mỗi vòng có 4 phần tương ứng với một pha.
 Cài đặt đối tượng: Chỉ ra các đối tượng của pha trong đề án. Những khó
khăn của quá trình và của sản phẩm được xác định và được lên kế hoạch chi tiết.
Xác định các yếu tố rủi ro của đề án. Các phương án thay thế tùy theo các rủi ro này
có thể được dự trù.

 Định lượng và giảm thiểu rủi ro. Tiến hành phân tích mỗi yếu tố rủi ro đã
xác định. Các bước đặt ra để giảm thiểu rủi ro
 Phát triển và đánh giá: Sau khi đánh giá các yếu tố rủi ro, một mô hình
phát triển cho hệ thống được chọn.
 Lên kế hoạch: Đề án được xem xét và quyết định có nên hay không tiếp
tục pha mới trong vòng lặp


16

Hình 1.4: Mô hình xoắn ốc

*Ưu điểm:
Phân tích đánh giá rủi ro được đẩy lên như một phần thiết yếu trong mỗi
“spiral” để tăng mức độ tin cậy của dự án.
Kết hợp những tính chất tốt nhất của mô hình waterfall và tiến hóa.
Cho phép thay đổi tùy theo điều kiện thực tế dự án tại mỗi “spiral”.
Đây chính là mô hình tổng quát nhất, tất cả các mô hình khác đều có thể xem
là một hiện thực của mô hình tổng quát này, hay cũng có thể xem nó là mô hình
tổng hợp các mô hình khác. Đặc biệt, nó được ứng dụng không chỉ trong phát triển
phần mềm mà còn trong phát triển phần cứng.
* Nhược điểm:
Phức tạp và không phù hợp cho dự án nhỏ với ít rủi ro.
Cần có kỹ năng tốt về phân tích rủi ro.
* Ứng dụng:


17

Dự án lớn có nhiều rủi ro hay sự thành công của dự án không có được sự đảm

bảo nhất định; những dự án đòi hỏi nhiều tính toán, xử lý như hệ thống hỗ trợ
quyết định.
Đội ngũ thực hiện dự án có khả năng phân tích rủi ro.

1.2.2. Mô hình Agile
1.2.3.1. Khái niệm chung
Phát triển phần mềm linh hoạt (agile software development – gọi tắt là Agile)
là một triết lí cùng với nhóm các phương pháp và phương pháp luận phát triển phần
mềm dựa trên các nguyên tắc phát triển phân đoạn lặp (iterative) và tăng trưởng
(incremental), theo đó nhu cầu và giải pháp tiến hóa thông qua sự hợp tác giữa các
nhóm tự quản và liên chức năng. Agile thường sử dụng cách lập kế hoạch thích ứng
(adaptive planning), việc phát triển và chuyển giao theo hướng tiến hóa; sử dụng
các khung thời gian ngắn và linh hoạt để dễ dàng phản hồi lại với các thay đổi trong
quá trình phát triển. Ngày nay, triết lí Agile đã vượt xa khỏi khu vực truyền thống
của mình là phát triển phần mềm để đóng góp sự thay đổi trong cách thức làm việc,
quản lí, sản xuất ở các ngành khác như sản xuất (manufacturing), dịch vụ, sales,
marketing, giáo dục v.v.
Thuật ngữ "Agile" chính thức được sử dụng rộng rãi theo cách thống nhất kể
từ khi “Tuyên ngôn Agile” được giới thiệu ra công chúng năm 2001. Nhờ tính linh
hoạt, đa dạng và hiệu quả cao, các phương pháp Agile ngày càng trở thành sự lựa
chọn hàng đầu của các khách hàng, nhà phát triển, các công ty phát triển phần mềm.

1.2.3.2. Bốn (04) tuyên ngôn trong Agile
Vào tháng 12 năm 2001, mười bảy nhà phát triển phần mềm đã gặp gỡ nhau ở
Snowbird, Utah Resort để thảo luận về các phương pháp phát triển phần mềm gọn
nhẹ và linh hoạt. Họ đã cùng nhau công bố “Tuyên ngôn Phát triển phần mềm linh
hoạt” (“Manifesto for Agile Software Development” – gọi tắt là “Tuyên ngôn
Agile”) để định nghĩa cách hiểu về Phát triển phần mềm linh hoạt. Đây là cột mốc