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

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

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

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ậpcủ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

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 tinquản lý Trường Đại học Kinh tế quốc dân, Trung tâm Nghiên cứu công nghệ mạngViettel đã 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ậntì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

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

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

UMTS Universal Mobile Telecommunications Service

BBNTNB Biên bản nghiệm thu nội bộ

TB Trung bì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

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ựcnà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ữngthá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ẩmnhanh, 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áchnhanh 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 conngườ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ụctì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ườigiao 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ầnmề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ầnmề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ấpdẫ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

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àotrong 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ôngnghệ thông tin, Trung tâm Nghiên cứu công nghệ mạng Viettel (VTTEK) luôn đặtmụ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ủakhá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 đó, BanGiá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 chokhá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 ChargingSystem_ Hệ thống tính cước online), MSS (Mobile Softswich_Hệ thống chuyểnmạ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ácnướ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ìnhnhư 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ự ánnghiê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àmchủ 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ươngchâ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áttriể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âmNghiên cứu phát triển thiết bị mạng viễn thông Viettel

- 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ôngnghệ 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òngtrong 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ụckị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 Trungtâ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ứutạ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áchạ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ìnhsả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ướcthự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

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áttriể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ự ánRTC_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ạiTrung 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âmNghiê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

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ạntheo xu hướng quy mô ngày càng thu nhỏ nhưng tính năng ngày càng đượcnâ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ủaphầ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ươngtrì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áthơ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ỹ RogerPressman Định nghĩa này nói rằng: phần mềm trong công nghệ phần mềm đượchiể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ềmlà một cấu trúc bao gồm tập hợp các thaotá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ảnphẩ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:

- Đặ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 đổicá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ệutrướ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àmtă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ệpkhá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

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ầntă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 theomộ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õitiế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ạchtổ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ảixâ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ũngnhư các chức năng cần có, hiệu năng và giao diện của phần mềm

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ácyê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ìnhphầ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ộtcá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ànhcá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 chokhá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èmkhi 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ăngsẵ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ềmnă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ếutrong 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

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ôngchỉ 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ùnghiể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 rakhi 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ềmphả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ạichứ 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ạnbả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ớinhữ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ápkiể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

Sản phẩm phần mềm được hình thành thông qua chuỗi các hoạt động xâydự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

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ủathờ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ớiphá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ôngviệc ở pha trước Trong thực tế, thời gian chờ đợi có thể vượt quá thời gian sảnxuấ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ìnhphần mềm

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ườiphá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 đếnviệ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ủaphầ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ầnphá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ãnnhu 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

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

Vi chỉnh yêu cầu

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ênquan đế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áchgiữ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ểnngắn (60-90 ngày) Để đạt được mục tiêu này, RAD dựa trên phương pháp pháttriể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ầnthí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ươngphá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

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

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 chialà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

đượ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ộtbả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ẫnphát triển

* 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átsinh Trong thực tế, nếu ứng dụng hợp lý, toàn bộ chi phí và thời gian cho đến khisả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

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 khaisớm một số phần của hệ thống

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 chothấ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ủaquá trình phần mềm Vòng trong cùng tập trung về tính khả thi, vòng kế lo về địnhnghĩ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ố địnhtrong 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

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ìnhtổ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ểnphầ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:

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ự đảmbả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ầnmề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ácnhó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ụngcá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 trongquá trình phát triển Ngày nay, triết lí Agile đã vượt xa khỏi khu vực truyền thốngcủ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 linhhoạ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ựachọ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ọnnhẹ và linh hoạt Họ đã cùng nhau công bố “Tuyên ngôn Phát triển phần mềm linhhoạt” (“Manifesto for Agile Software Development” – gọi tắt là “Tuyên ngônAgile”) để đị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

quan trọng của agile Dù trước đó, các phương pháp agile như XP, Scrum, v.v đãđược sử dụng thành công ở rất nhiều nơi, nhưng phải tới khi có sự xuất hiện của

“Tuyên ngôn Agile”, cùng với sự ra đời của các hiệp hội chuyên ngành agile nhưAgile Alliance hay Scrum Alliance, các phương pháp agile mới có một sự phát triểnvượt bậc Văn bản này rất ngắn, dễ hiểu, và rất quan trọng vì nó đưa ra các giá trịcốt lõi nhất mà toàn bộ các nhà lý thuyết cũng như những người thực hành Agiletuân thủ; mặc dù các phương pháp họ đề xuất hoặc sử dụng trong thực tiễn có thểrất khác nhau Toàn văn Tuyên ngôn Agile như sau:

 Cá nhân và sự tương tác hơn là quy trình và công cụ

 Phần mềm chạy tốt hơn là tài liệu đầy đủ

 Cộng tác với khách hàng hơn là đàm phán hợp đồng

 Phản hồi với các thay đổi hơn là bám sát kế hoạch

Bên cạnh đó, các nhà phát triển còn nhấn mạnh mười hai nguyên lý phía sauTuyên ngôn Agile để giúp các nhà phát triển có được gợi ý trong thực hành và vậndụng các phương pháp agile trong thực tiễn Các nguyên lý được liệt kê sau đây:

 Ưu tiên cao nhất của chúng tôi là thỏa mãn khách hàng thông qua việcchuyển giao sớm và liên tục các phần mềm có giá trị

 Chào đón việc thay đổi yêu cầu, thậm chí rất muộn trong quá trình pháttriển Các quy trình linh hoạt tận dụng sự thay đổi cho các lợi thế cạnh tranh củakhách hàng

 Thường xuyên chuyển giao phần mềm chạy tốt tới khách hàng, từvài tuần đến vài tháng, ưu tiên cho các khoảng thời gian ngắn hơn

 Nhà kinh doanh và nhà phát triển phải làm việc cùng nhau hàngngày trong suốt dự án

 Xây dựng các dự án xung quanh những cá nhân có động lực Cung cấpcho họ môi trường và sự hỗ trợ cần thiết, và tin tưởng họ để hoàn thành công việc

 Phương pháp hiệu quả nhất để truyền đạt thông tin tới nhóm phát triển vàtrong nội bộ nhóm phát triển là hội thoại trực tiếp

 Phần mềm chạy tốt là thước đo chính của tiến độ

 Các quy trình linh hoạt thúc đẩy phát triển bền vững Các nhà tài trợ, nhàphát triển, và người dùng có thể duy trì một nhịp độ liên tục không giới hạn.

 Liên tục quan tâm đến các kĩ thuật và thiết kế tốt để gia tăng sự linh hoạt

 Sự đơn giản – nghệ thuật tối đa hóa lượng công việc chưa xong – là căn bản

 Các kiến trúc tốt nhất, yêu cầu tốt nhất, và thiết kế tốt nhất sẽ được làm rabởi các nhóm tự tổ chức

 Đội sản xuất sẽ thường xuyên suy nghĩ về việc làm sao để trở nên hiệuquả hơn, sau đó họ sẽ điều chỉnh và thay đổi các hành vi của mình cho phù hợp

1.2.3.3 Đặc trưng của Agile

Có rất nhiều phương pháp agile với các hướng tiếp cận rất khác nhau Bêncạnh các cách thức tổ chức công việc, thiết lập quy trình, các phương pháp agile cònnghiên cứu và đưa vào sử dụng các công cụ và kĩ thuật đặc thù như công cụ tíchhợp liên tục (continuous integration), kiểm thử đơn vị, mẫu thiết kế, tái cấu trúc,phát triển hướng kiểm thử (TDD), phát triển hướng hành vi (BDD), hay lập trìnhtheo cặp v.v để đảm bảo và gia tăng tính linh hoạt Tuy vậy các phương pháp nàychia sẻ nhiều đặc trưng giống nhau cộng tác nhóm chặt chẽ, tổ chức các nhóm tựquản, liên chức năng, tính đáp ứng cao trong suốt vòng đời của dự án

* Tính lặp (iterative)

Dự án sẽ được thực hiện trong các phân đoạn lặp đi lặp lại Các phân đoạn(được gọi là Iteration hoặc Sprint) này thường có khung thời gian ngắn (từ một đếnbốn tuần) Trong mỗi phân đoạn này, nhóm phát triển thực hiện đầy đủ các côngviệc cần thiết như lập kế hoạch, phân tích yêu cầu, thiết kế, triển khai, kiểm thử (vớicác mức độ khác nhau) để cho ra các phần nhỏ của sản phẩm Các phương phápagile thường phân rã mục tiêu thành các phần nhỏ với quá trình lập kế hoạch đơngiản và gọn nhẹ nhất có thể, và không thực hiện việc lập kế hoạch dài hạn Cóphương pháp như Scrum thậm chí sử dụng phương pháp lập kế hoạch just-in-timetrong quá trình phát triển Khi đó, thậm chí công việc lập kế hoạch, làm mịn kếhoạch được thực hiện liên tục trong suốt quá trình làm việc

*Tính tiệm tiến (Incremental) và tiến hóa (Evolutionary)

Cuối các phân đoạn, nhóm phát triển thường cho ra các phần nhỏ của sảnphẩm cuối cùng Các phần nhỏ này thường là đầy đủ, có khả năng chạy tốt, đượckiểm thử cẩn thận và có thể sử dụng ngay (gọi là potentially shippable productincrement of functionality) Theo thời gian, phân đoạn này tiếp nối phân đoạn kia,các phần chạy được này sẽ được tích lũy, lớn dần lên cho tới khi toàn bộ yêu cầucủa khách hàng được thỏa mãn Khác với mô hình phát triển Thác nước – vốn chỉcho phép nhìn thấy toàn bộ các chức năng tại thời điểm kết thúc dự án, sản phẩmtrong các dự án agile lớn dần lên theo thời gian, tiến hóa cho tới khi đạt được trạngthái đủ để phát hành

* Tính thích ứng(adaptive):

Do các phân đoạn chỉ kéo dài trong một khoảng thời gian ngắn, và việc lập kếhoạch cũng được điều chỉnh liên tục, nên các thay đổi trong quá trình phát triển(yêu cầu thay đổi, thay đổi công nghệ, thay đổi định hướng về mục tiêu v.v.) đều cóthể được đáp ứng theo cách thích hợp Ví dụ, trong Scrum – phương pháp phổ biếnnhất hiện nay – trong khi nhóm phát triển sản xuất ra các gói phần mềm, kháchhàng có thể đưa thêm các yêu cầu mới, chủ sản phẩm (Product Owner) có thể đánhgiá các yêu cầu này và có thể đưa vào làm việc trong phân đoạn (được gọi là Sprinttrong Scrum) tiếp theo Theo đó, các quy trình agile thường thích ứng rất tốt với cácthay đổi

*Nhóm tự tổ chức và liên chức năng

Cấu trúc nhóm agile thường làliên chức năng(cross-functionality) và tự tổchức(self-organizing) Theo đó, các nhóm này tự thực hiện lấy việc phân công côngviệc mà không dựa trên các mô tả cứng về chức danh (title) hay làm việc dựa trênmột sự phân cấp rõ ràng trong tổ chức Các nhóm này cộng tác với nhau để ra quyếtđịnh, theo dõi tiến độ, giải quyết các vấn đề mà không chờ mệnh lệnh của các cấpquản lý Họ không làm việc theo cơ chế “mệnh lệnh và kiểm soát” (command andcontrol) Nhóm tự tổ chức có nghĩa là nó đã đủ các kĩ năng (competency) cần thiết

cho việc phát triển phần mềm, do vậy nó có thể được trao quyền để tự ra quyết định,

tự quản lí và tổ chức lấy công việc của chính mình để đạt được hiệu quả cao nhất

* Quản lý tiến trình thực nghiệm:

Các nhóm agile ra các quyết định dựa trên các dữ liệu thực tiễn thay vì tínhtoán lý thuyết hay các tiền giả định (prescription) Việc phân nhỏ dự án thành cácphân đoạn ngắn góp phần gia tăng các điểm mốc để nhóm phát triển thu thập dữkiện cho phép điều chỉnh các chiến lược phát triển của mình Nói cách khác, Agilerút ngắn vòng đời phản hồi (short feedback life cycle) để dễ dàng thích nghi và giatăng tính linh hoạt Theo thời gian, các chiến lược này sẽ tiến gần đến trạng thái tối

ưu, nhờ đó nhóm có thể kiểm soát được tiến trình, và nâng cao năng suất lao động

*Giao tiếp trực tiếp

Một số mô hình phát triển phần mềm dựa rất nhiều vào công việc giấy tờ, từviệc thu thập yêu cầu người dùng, viết đặc tả hệ thống, các thiết kế hệ thống v.v.Agile không phản đối công dụng của công việc tài liệu hóa, nhưng đánh giá cao hơnviệc giao tiếp trực diện thay vì gián tiếp thông qua giấy tờ Về yêu cầu của kháchhàng, agile khuyến khích nhóm phát triển trực tiếp nói chuyện với khách hàng đểhiểu rõ hơn về cái khách hàng thực sự cần, thay vì phụ thuộc nhiều vào các loại vănbản Trong giao tiếp giữa nội bộ nhóm phát triển với nhau, thay vì một lập trìnhviên (thực hiện việc mã hóa) và một kĩ sư (thực hiện việc thiết kế) giao tiếp vớinhau thông qua bản thiết kế, agile khuyến khích hai người này trực tiếp trao đổi vàthống nhất với nhau về thiết kế của hệ thống và cùng nhau triển khai thành các chứcnăng theo yêu cầu

Bản thân các nhóm agile thường nhỏ (ít hơn mười hai người, một nhóm lớnthường được phân nhỏ với cơ chế hợp tác đặc thù để luôn luôn có thông lượng giaotiếp tối đa) để đơn giản hóa quá trình giao tiếp, thúc đẩy việc cộng tác hiệu quả Các

dự án lớn muốn dùng agile thường phải phân thành nhóm nhỏ đồng thời làm việcvới nhau hướng đến một mục tiêu chung Việc này có thể đòi hỏi một số nỗ lựcđáng kể trong việc điều phối các mức ưu tiên giữa các nhóm

Các nhóm phát triển thường tạo ra các thói quen và cơ chế trao đổi trực diệnmột cách thường xuyên Một trong các cơ chế thường thấy là các cuộc họp tập trunghằng ngày (daily meeting, Daily Scrum, standup meeting) Tại đây, tất cả các thànhviên được yêu cầu nói rõ cho nhóm của mình biết mình đã làm gì, đang làm gì, sắplàm gì và đang gặp phải khó khăn nào trong quá trình làm việc Khi cơ chế nàyđược thực hiện hiệu quả, nhóm luôn luôn nắm được tình hình công việc của mình,

có các hành động thích hợp để vượt qua các trở lực để thực hiện thành công mụctiêu của dự án

* Phát triển dựa trên giá trị:

Một trong các nguyên tắc cơ bản của agile là “phần mềm chạy tốt chính làthước đo của tiến độ” Nguyên tắc này giúp nhóm dám loại bỏ đi các công việc dưthừa không trực tiếp mang lại giá trị cho sản phẩm Ví dụ, một nhóm thấy rằng cóthể không cần phải viết ra tất cả các thiết kế của hệ thống, mà họ chỉ cần phác thảocác thiết kế này lên bảng, rồi cùng nhau triển khai các chức năng của hệ thống.Nhưng nếu như chủ sản phẩm quyết định rằng, khi chuyển giao sản phẩm, nhómphát triển phải kèm theo thiết kế chi tiết của hệ thống vì chúng chiếm 20% giá trịcủa dự án theo yêu cầu của khách hàng, và vì khách hàng cần nó để chứng minhtính đúng đắn của các chức năng, và để phát triển tiếp các phân hệ tiếp theo của sảnphẩm; thì nhóm phát triển sẽ phải thực hiện việc tài liệu hóa đầy đủ

Để vận hành được cơ chế “làm việc dựa trên giá trị”, nhóm agile thường làmviệc trực tiếp và thường xuyên với khách hàng (hay đại diện của khách hàng), cộng

tác trực tiếp với họ để biết yêu cầu nào có độ ưu tiên cao hơn, mang lại giá trị hơn sớm nhất có thể cho dự án Nhờ đó các dự án agile thường giúp khách hàng tối

ưu hóa được giá trị của dự án Một cách gần như trực tiếp, agile gia tăng đáng kể độhài lòng của khách hàng

1.2.3.4 Một số các phương pháp trong Agile

Theo khảo sát của VersionOne khảo sát trên các công ty Agile, cho thấynhững phương pháp phổ biến được sử dụng:

Hình 1.5: Tỉ lệ phương pháp Agile được dùng trên thế giới

Theo khảo sát của Forrester Research năm 2011 các cách tiếp cận phổ biếntrong phát triển phần mềm có thể kể đến gồm Scrum, Iterative (IterativeDevelopment - phát triển lặp), Waterfall, TDD, Kanban, XP Cụ thể như sau:

Lean Software Development 32.7%

Theo như 2 nghiên cứu, thống kê phía trên phương pháp Scrum là phươngpháp được sử dụng rộng rãi và phổ biến nhất Phần lớn các công ty hiện nay đã bắtđầu sử dụng Scrum như là cách tiếp cận cơ bản Bên cạnh đó, nhiều công ty đã kếthợp các phương pháp lại với nhau trong thực tiễn Ví dụ 44.4 % các công ty có sử

dụng Waterfall, như vậy có nghĩa là một tỉ lệ nhất định nào đó vừa dùng waterfall,vừa sử dụng Scrum trong hoạt động của mình Điều này có thể do các nguyên nhânlịch sử, hoặc các ràng buộc về chính sách, luật pháp hoặc văn hóa Đó cũng là mộttình huống khá phổ biến đối với các công ty mới lần đầu “bước chân” vào “ma trậncác phương pháp Agile”

a Scrum

Scrum là một khung làm việc với đặc tính lặp và tiệm tiến dành cho các dự án

và phát triển sản phẩm hay ứng dụng Scrum tổ chức việc phát triển thành các chutrình làm việc gọi là Sprint Mỗi Sprint không quá một tháng và không có ngắtquãng giữa các Sprint Các Sprint được đóng khung thời gian kết thúc vào một ngàyxác định kể cả khi công việc đã hoàn thành hay chưa và không bao giờ kéo dàithêm Bắt đầu mỗi Sprint, nhóm liên chức năng chọn các hạng mục từ danh sách ưutiên hóa Nhóm phát triển cam kết hoàn thành các hạng mục khi kết thúc Sprint.Trong Sprint các hạng mục đã được chọn không thay đổi Mỗi ngày nhóm phát triểntập hợp trong thời gian ngắn để thanh tra quá trình thực hiện và điều chỉnh nhữngbước cần thiết tiếp theo để hoàn thành công việc còn lại Kết thúc Sprint, nhóm sơkết lại Sprint với các bên liên quan và trình bày các việc đã làm Mọi người nhậnphản hồi để đưa vào Sprint tiếp theo Scrum quan tâm đến phần thật sự đã hoànthành của sản phẩm ở cuối mỗi Sprint; đối với phần mềm có nghĩa là mã nguồn đãhoàn chỉnh, đã được kiểm thử đầy đủ, có thể chuyển giao được

Điểm mấu chốt nhất của Scrum chính là cơ chế thanh tra và thích nghi Vìtrong quá trình phát triển không bao giờ tránh được việc học hỏi, đổi mới, và cácyếu tố bất ngờ; Scrum nhấn mạnh việc đi từng bước nhỏ, thanh tra cả kết quả sảnphẩm lẫn hiệu quả công việc thực tại, để từ đó thích ứng với các mục tiêu của sảnphẩm cũng như quy trình thực tế Và cứ thế lặp đi lặp lại như vậy

Hình 1.6: Phương pháp Scrum

* Vai trò trong Scrum: Trong Scrum có 3 vai trò: Product Owner (PO_Chủ sản

phẩm), nhóm phát triển và Scrum Master Tất cả được gọi là nhóm Scrum

Vai trò của PO: chịu trách nhiệm tối đa hóa giá trị của sản phẩm và công việc

của Nhóm Phát triển Cách thức để đạt được điều đó có thể rất khác nhau tùy thuộc

tổ chức, Nhóm Scrum và cá nhân Chủ Sản phẩm là một người chủ yếu chịu tráchnhiệm chính về việc quản lý Product Backlog Việc quản lý Backlog bao gồm:

 Mô tả rõ ràng các hạng mục Product backlog;

 Thứ tự của các hạng mục trong Product Backlog sao cho đạt được mụcđích và hoàn thành các nhiệm vụ một cách tốt nhất;

 Tối ưu hóa giá trị công việc mà Nhóm Phát triển thực hiện;

 Đảm bảo cho Product Backlog là luôn luôn rõ ràng/hiện hữu, minhbạch với tất cả mọi người, và chỉ ra những gì mà Nhóm Scrum sẽ làm;

và,

 Đảm bảo cho Nhóm Phát triển hiểu rõ các hạng mục trong ProductBacklog cũng như mức độ cần thiết tương ứng.

Chủ Sản phẩm có thể tự mình thực hiện công việc trên, hoặc để Nhóm Pháttriển làm Tuy nhiên, Chủ Sản phẩm vẫn phải chịu trách nhiệm chính Chủ Sảnphẩm là một người, không phải là một nhóm người Chủ Sản phẩm có thể đại diệncho một nhóm người nhưng nếu ai trong nhóm đó muốn thay đổi độ ưu tiên củahạng mục trong Backlog thì cần thông qua Chủ Sản phẩm Để Chủ Sản phẩm thànhcông, toàn bộ tổ chức/công ty phải tôn trọng quyết định của anh ta Các quyết định

đó được hiển thị trong nội dung và thứ tự trong Product Backlog Không ai ngoàiChủ Sản phẩm được yêu cầu Nhóm Phát triển làm theo yêu cầu khác Tương tự,Nhóm Phát triển cũng không được làm gì theo lời bất cứ người nào khác

Vai trò của nhóm phát triển: Nhóm Phát triển gồm các chuyên gia làm việc

và cho ra các phần tăng trưởng có thể phát hành được cuối mỗi Sprint Chỉ cácthành viên của Nhóm Phát triển mới tạo ra các phần tăng trưởng này Nhóm Pháttriển được tổ chức và trao quyền bởi tổ chức/công ty để quản lý công việc của họ

Sự hợp lực sẽ giúp tối ưu tổng thể hiệu suất và hiểu quả làm việc của Nhóm Pháttriển Nhóm Phát triển có các đặc trưng sau:

 Là nhóm tự quản Không ai (kể cả Scrum Master) có quyền yêu cầuNhóm Phát triển làm thế nào để chuyển Product Backlog thành các phần tăngtrưởng có thể chuyển giao được;

 Là nhóm liên chức năng, có tất cả các kĩ năng cần thiết để tạo ra phầntăng trưởng của sản phẩm;

 Scrum không chấp nhận một chức danh nào trong Nhóm Phát triển ngoàiNgười Phát triển bất kể nội dung công việc của anh ta là gì; không có ngoại lệ chonguyên tắc này;

 Nhóm Phát triển không chứa các nhóm con nào khác với các chức năngđặc thù như "nhóm kiểm thử" hay "phân tích nghiệp vụ";

 Một cá nhân trong Nhóm phát triển có thể có một số khả năng hoặc sự tậptrung đặc biệt, nhưng trách nhiệm vẫn thuộc về CẢ nhóm phát triển

Vai trò của Scrum Master: Scrum Master chịu trách nhiệm đảm bảo rằng

Scrum được hiểu (đúng) và được thực thi Scrum Master thực hiện việc này bằngcách đảm bảo rằng Nhóm Scrum tuân thủ lý thuyết, các kĩ thuật thực hành và cácquy tắc của Scrum Scrum Master một servant-leader (lãnh đạo theo cách “phục vụ”Nhóm) Scrum Master giúp đỡ những người ngoài Nhóm Scrum hiểu cách họ tươngtác với Nhóm hiệu quả nhất Scrum Master cũng giúp đỡ mọi người thay đổi cácmối tương tác này để tối đa hóa giá trị mà Nhóm Scrum tạo ra

Vai trò của Scrum Master đối với PO:

 Tìm kiếm các kĩ thuật để quản lý hiệu quả Product Backlog;

 Giúp Nhóm Scrum hiểu sự cần thiết của hạng mục Product Backlog rõràng và súc tích;

 Hiểu việc lên kế hoạch cho sản phẩm trong môi trường thực nghiệm;

 Đảm bảo rằng Chủ Sản phẩm hiểu cách bố trí Product Backlog sao chogiá trị đạt được lớn nhất;

 Hiểu rõ và thực hành sự linh hoạt; và,

 Tạo điều kiện cho các sự kiện Scrum khi cần hoặc được yêu cầu

Vai trò của Scrum Master đối với nhóm phát triển:

 Huấn luyện Nhóm Phát triển cách tự tổ chức và làm việc liên chức năng;

 Giúp đỡ Nhóm Phát triển để tạo ra các sản phẩm có giá trị cao;

 Loại bỏ các rào cản trong quá trình làm việc của Nhóm Phát triển;

 Tạo điều kiện cho các sự kiện Scrum theo yêu cầu hoặc khi cần thiết; và,

 Huấn luyện Nhóm Phát triển trong trường hợp tổ chức/công ty chưa cóhiểu biết và ứng dụng đầy đủ về Scrum

*Các công cụ sử dụng trong Scrum:

Product Backlog: Danh sách ưu tiên mô tả các tính năng và kết quả của sản

phẩm, có thể chỉnh sửa được Đặc điểm Product Backlog:

 Mỗi sản phẩm chỉ có một Product Backlog

 Danh sách các tính năng (chức năng & phi chức năng)

 Nổi bật, ưu tiên hóa và được ước tính

 Chi tiết hơn với các hạng mục có độ ưu tiên cao hơn

 Chi tiết hơn với các hạng mục có độ ưu tiên cao hơn

 Luôn luôn hiện diện cho các bên

 Có nguồn gốc từ Kế hoạch Kinh doanh hoặc Tuyên bố Tầm nhìn

 Các nội dung tùy chọn: Rủi ro, kiểm thử, các sản phẩm phụ thuộc,người hiểu rõ về một hạng mục,…

Sprint Backlog: Danh sách các công việc cần hoàn thành trong Sprint, được

cập nhật hàng ngày Là công cụ lên kế hoạch và theo dõi trong một Sprint, được bảotrì bởi Nhóm Phát triển Đặc điểm của Sprint Backlog:

 Sprint luôn cho thấy khối lượng công việc còn lại để hoàn thành Mụctiêu Sprint

 Sprint Backlog KHÔNG phải là công cụ để kiểm soát thời gian

 Năng suất được đo bằng việc đạt tới Mục tiêu Sprint, nó hướng tới kếtquả chứ không bởi ta bỏ ra bao nhiêu nguồn lực

Biểu đồ Burndown: Hiển thị xu hướng về “thời gian còn lại để hoàn tất công

việc”, cho biết tiến độ hướng đến Mục tiêu

* Các sự kiện của Scrum:

- Họp kế hoạch Sprint:

Mục tiêu của buổi họp:

 Thiết lập mục tiêu của Sprint

 Lựa chọn các việc cho Sprint và làm rõ cách để đạt được chúng

Các bước thực hiện:

 Nhóm Scrum chọn các hạng mục có độ ưu tiên cao nhất từ ProductBacklog để làm trong Sprint dựa theo năng lực (capacity) của nhóm

 Xác định mục tiêu của Sprint:

o Phân tích Product Backlog

o Xác định mục tiêu Sprint

o Lựa chọn công việc cho Sprint

 Tạo ra Sprint backlog: Xác lập Mục tiêu Sprint

o Làm thế nào để đạt được Mục tiêu Sprint (phân tích - thiết kế)

o Tạo Sprint Backlog

o Ước tính công việc ra giờ

- Họp hàng ngày: đây là cuộc họp ngắn kéo dài khoảng 15 phút tại một địa điểm đã

được ấn định trước Mục tiêu của buổi họp:

 Đồng bộ hóa công việc

 Cập nhật kế hoạch và tiến bộ

Nội dung của buổi họp trả lời 3 câu hỏi

 Đã làm được gì kể từ lần họp trước?

 Sẽ làm gì từ giờ cho tới lần họp tiếp theo?

 Có khó khăn gì trong công việc?:

- Sơ kết Sprint:

Mục tiêu của buổi họp

 Sơ kết các công việc đã hoàn thành trong Sprint

 Kiểm tra có đạt mục tiêu của Sprint hay không

Các bước thực hiện:

 Nhóm Phát triển trình bày những hạng mục đã “hoàn thành” củaProduct Backlog cho Product Owner và các bên liên quan

 Khung thời gian: 4 giờ

 Thành phần: Nhóm Scrum (pig) + các bên liên quan(chicken) • Khôngtrình bày những tính năng chưa “hoàn thành”

 Các phản hồi được đưa ra – Product Backlog có thể được đánh giá lại

độ ưu tiên

 Đây không phải buổi DEMO, chuẩn bị ít hơn 30 phút

 Product Owner nên sử dụng kĩ thuật kiểm thử chấp nhận để đánh giácác tính năng

- Cải tiến Sprint:

Mục tiêu của buổi họp:

 Rà soát quy trình thực hiện

 Tìm kiếm sự cải tiến để đạt được hiệu quả cao nhất

Các bước thực hiện:

 Dừng và nhìn lại, tìm kiếm các cải tiến và xây dựng tổ chức học tập

 Khung thời gian: 3 giờ

 Thành phần: Scrum Master + Nhóm Phát triển

 Câu hỏi

o Đã làm tốt những gì?

o Phải cải thiện những gì?

 Scrum Master trợ giúp nhóm tìm hiểu, không đưa ra câu trả lời

* Một số trở ngại với Scrum: Theo Bas Vodde

 Những ảo tưởng về mệnh lệnh và điều khiển

 Vẫn giữ các lề thói cũ

 Trông chờ phép màu nào đó

 Thiếu sự minh bạch

 “Quán tính Waterfall”

* Nguyên nhân thất bại của Scrum:

 Sử dụng không hiệu quả hoạt động cải tiến

 Không có khả năng lôi kéo tất cả mọi người cùng tham gia vào lập kếhoạch

 Không chú ý tới cơ sở hạ tầng cần thiết

 Scrum Master tồi

 Product Owner không giữ được sự nhất quán

 Thất bại trong việc thúc đẩy hoạt động kiểm thử

 Khôi phục lại khuôn mẫu trước đây

 Chỉ quan tâm tới “cam kết sổ sách" từ phía quản lý điều hành

 Nhóm thiếu thẩm quyền và khả năng ra quyết định

 Không có người chịu trách nhiệm truyền đạt khi tiến hành làm việcphân tán

 Văn hóa của tổ chức không hỗ trợ việc học tập

 Từ chối chấp nhận một cách gay gắt

b Một số phương pháp phát triển linh hoạt khác

- 7 nguyên lý tinh gọn: Loại bỏ lãng phí, Khuếch trương việchọc, quyết định càng muộn càng tốt, Chuyển giao càng nhanhcàng tốt, trao quyền cho nhóm, tạo ra tính toàn vẹn tự thân,thấy toàn cảnh

Crystal family of

methodologies

- Là tập hợp của các phương pháp, mỗi cái có cùng một giátrị ban đầu và nguyên tắc cơ bản về kĩ thuật, vai trò, công cụ

và tiêu chuẩn thì có thể khác nhau

- Thiết kế phương pháp theo nguyên tắc Có thể chọn phươngpháp thích hợp nhât dựa vào quy mô và giới hạn của dự án

- Sự đơn giản trong phương pháp, thiết kế và thực hiện hệthống bằng cách mô hình hóa đối tượng và đặc điể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

2.1 Tổng quan về Trung tâm Nghiên cứu công nghệ mạng Viettel.

2.1.1 Giới thiệu chung

Tên đầy đủ: Trung tâm Nghiên cứu công nghệ mạng Viettel

Tên giao dịch: VTTEK

Địa chỉ: Số 1, Trần Hữu Dực, Mỹ Đình, Hà Nội

2.1.1.1 Quan điểm xây dựng

Trung tâm VTTEK ưu tiên phát triển các sản phẩm mạng viễn thông phục vụhoạt động sản xuất kinh doanh của Tập đoàn và định hướng kinh doanh quốc tế

Tổ chức bộ máy chuyên môn hóa theo lĩnh vực sản xuất, tối ưu hóa nguồn lựclàm ở mức độ cao nhất, khó nhất (Design), xác định làm chủ hoàn toàn phần mềm,sau đó tiến tới làm chủ phần cứng

VTTEK là đơn vị hạch toán phụ thuộc trực thuộc Tập đoàn, có tài khoản, condấu riêng và thực hiện đăng ký hoạt động dưới hình thức Chi nhánh (đơn vị hạchtoán phụ thuộc) theo quy định của pháp luật

2.1.1.2 Mục tiêu của Trung tâm

Làm chủ hệ thống: Có đội ngũ nhân sự trình độ chuyên môn cao, thấm nhuầnvăn hóa, gắn bó với Viettel, nắm vững và làm chủ các hệ thống phần mềm củaViettel

Phát triển các sản phẩm đáp ứng nhu cầu phát triển thị trường viễn thông trongnước và quốc tế