Bài giảng Công nghệ phần mềm - Phạm Thị Minh Thương

Bài giảng Công Nghệ Phần Mềm

Chương 1:

PHẦN MỀM

TIẾN TRÌNH VÀ QUẢN LÝ

1.1 Phần mềm và công nghệ phần mềm

1.1.1 Lịch sử và mục tiêu của công nghệ phần mềm

Ngay từ khi xuất hiện các hệ máy tính và ngôn ngữ lập trình đầu tiên thì

phần mềm cũng bắt đầu xuất hiện. Tuy nhiên, khi 1 loại phần cứng mới được

giới thiệu – phần cứng dựa vào dòng điện tích hợp (integrated circuits) hay còn

gọi là chip điện tử - thì việc phát triển phần mềm rơi vào khủng hoảng.

-

Các đơn đặt hàng yêu cầu phần mềm có kích thước lớn và độ phức tạp

cao ngày càng nhiều, trong khi việc phát triển phần mềm theo cách từ trước

ngày càng không phù hợp.

-

Nhiều dự án lớn bị trễ 1 thời gian dài.

Chi phí phần mềm lớn hơn nhiều so với dự đoán.

Phần mềm ngày càng không đáng tin cậy, khó bảo trì và thực thi 1 cách

nghèo nàn (performed poorly).

Do đó, để kiểm soát (control) độ phức tạp này, những kỹ thuật và

phương pháp mới cần được sử dụng và công nghệ phần mềm ra đời.

1.1.1.1 Định nghĩa “Công nghệ phần mềm”

Có nhiều định nghĩa về CNPM:

-

Theo Fritz Bauer [1969]: CNPM là sự thiết lập và sử dụng những

nguyên tắc công nghệ hợp lý để đạt được những phần mềm có tính kinh tế mà

đáng tin cậy và làm việc hiệu quả trên máy thực.

-

Theo IEEE [1993]: CNPM là (1) việc áp dụng phương pháp tiếp cận có

tính hệ thống, bài bản và số lượng xác định trong việc phát triển, hoạt động và

bảo trì phần mềm; đó là việc áp dụng công nghệ vào phần mềm. (2) nghiên cứu

các phương pháp tiếp cận ở (1).

-

Theo Roger S. Pressman: CNPM là bộ môn tích hợp cả các quy trình,

các phương pháp, các công cụ để phát triển phần mềm máy tính.

GV: Pham Thị Minh Thương

1

Bài giảng Công Nghệ Phần Mềm

Theo Ian Sommerville: CNPM là 1 lĩnh vực mà liên quan đến tất cả

-

các khía cạnh của sản xuất phần mềm từ những giai đoạn đầu của đặc tả hệ

thống đến bảo trì hệ thống sau khi nó đã được đưa vào sử dụng.

1.1.1.2 Lịch sử ra đời

Năm 1968: tại Tây Đức, hội nghị khoa học của NATO đã đưa ra từ

“Software Engineering” (Công nghệ phần mềm). Bắt đầu bàn luận về khủng

hoảng phần mềm (Software Crisis) và xu hướng hình thành CNPM như 1

chuyên môn riêng.

Nửa cuối 1968: IBM đưa ra chính sách phân biệt giá cả giữa phần cứng

và phần mềm. Từ đó, ý thức về phần mềm ngày càng cao. Bắt đầu những

nghiên cứu cơ bản về phương pháp luận lập trình.

Nửa đầu những năm 1970: Nhằm nâng cao chất lượng phần mềm,

không chỉ có các nghiên cứu về lập trình, kiểm thử, mà còn có cả những nghiên

cứu đảm bảo tính tin cậy trong quá trình sản xuất phần mềm.

Năm 1975: Hội nghị quốc tế đầu tiên về CNPM được tổ chức:

International Conference on SE (ICSE).

Nửa sau những năm 1970: Quan tâm đến mọi pha trong quá trình phát

triển phần mềm, nhưng tập trung chính ở những pha đầu. ICSE tổ chức lần 2, 3

và 4 vào 1976, 1978 và 1979.

-

1981.

-

Nhật Bản có “Kế hoạch phát triển kỹ thuật sản xuất phần mềm” từ năm

Cuộc “Cách tân sản xuất phần mềm” đã bắt đầu trên phạm vị các nước

công nghiệp.

Nửa đầu những năm 1980: Trình độ học vấn và ứng dụng CNPM được

nâng cao, các công nghệ được chuyển vào thực tế. Xuất hiện các sản phẩm

phần mềm và các công cụ khác nhau làm tăng năng suất sản xuất phần mềm

đáng kể.

-

ICSE tổ chức lần 5 và 6 vào năm 1981 và 1982 với trên 1000 người

tham dự mỗi năm.

-

Nhật Bản sang “Kế hoạch phát triển các kỹ thuật bảo trì phần mềm”

(1981 – 1985).

GV: Pham Thị Minh Thương

2

Bài giảng Công Nghệ Phần Mềm

Nửa cuối những năm 1980 đến nay: Từ học vấn sang nghiệp vụ. Chất

lượng phần mềm tập trung chủ yếu ở tính năng suất, độ tin cậy và tính bảo trì.

Nghiên cứu tự động hóa sản xuất phần mềm.

-

Nhật Bản có “Kế hoạch hệ thống công nghiệp hóa sản xuất phần mềm”

(SIGMA: Software Industrialized Generator & Maintenance Aids, 1985-1990).

Nhiều trung tâm, viện nghiên cứu CNPM ra đời. Các trường đưa vào

-

giảng dạy SE.

1.1.1.3 Mục tiêu

Là cung cấp 1 cấu trúc cho việc xây dựng phần mềm có chất lượng cao:

tính đúng đắn và độ tin cậy cao, dễ sử dụng, thân thiện với người dùng, dễ

hiểu,…

1.1.2 Tiêu chuẩn của một sản phẩm phần mềm

Để đánh giá một sản phẩm phần mềm, người ta thường đánh giá theo 2

khía cạnh: chất lượng bên trong (internal qualities) và chất lượng bên ngoài

(external qualities).

1.1.2.1 Chất lượng bên ngoài

Người dùng sẽ đánh giá chất lượng 1 phần mềm thông qua những yếu tố

của chất lượng bên ngoài, như: tính dễ sử dụng, tính tin cậy, tính chức năng,….

Những yếu tố này sẽ bao gồm cả thuộc tính chức năng (functional attributes) và

thuộc tính phi chức năng (non-functional attributes). Những thuộc tính chức

năng sẽ miêu tả những chức năng mà sản phẩm phần mềm phải thực hiện

(describe WHAT the product MUST do), trong khi những thuộc tính phi chức

năng lại miêu tả về cách thức chương trình thực thi (describe HOW the product

SHOULD be implemented).

Các yếu tố chất lương bên ngoài sẽ được xem xét thông qua một số câu

hỏi đi kèm:

- Tính dễ sử dụng (usability): giao diện có thân thiện không? Các thao tác

thực hiện có gần gũi không?,…

- Tính tin cậy (reliability): các chức năng của chương trình đều thực hiện

đúng chứ? Các công thức tính toán đều cho ra kết quả đúng như mong muốn?

GV: Pham Thị Minh Thương

3

Bài giảng Công Nghệ Phần Mềm

các dữ liệu được lưu vào trong DB đúng như mong muốn? phần mềm chạy ổn

định?

- Tính chức năng (functionality): từng chức năng đều thực hiện đúng? Các

công thức tính toán đều cho ra kết quả đúng như mong muốn? Các dữ liệu

được lưu vào trong DB đúng như mong muốn?... Tính chức năng tuy cũng trả

lời 1 số câu hỏi giống như tính tin cậy nhưng nó chỉ xét trên phạm vi 1 chức

năng. Giả sử khi phần mềm có 5 chức năng: tính đúng đắn chỉ quan tân đến

từng chức năng riêng rẽ, trong khi tính tin cậy sẽ quan tâm đến sự lien kết, rang

buộc giữa các chức năng này với nhau.

- Tính bền vững (stability): phần mềm có thể hoạt động trong những điều

kiện khác nhau? Trong những môi trường khác nhau?

- Tính tương thích (compatibility): phần mềm có thể dễ dàng tích hợp với

các sản phẩm phần mềm khác?

- Tinh thực thi (performance): phần mềm chạy với tốc độ nhanh hay

chậm? khi chạy có sử dụng nhiều tài nguyên của máy tính không: bộ nhớ, bộ

xử lý,…?

Do những yếu tố chất lượng bên ngoài là do người dùng đánh giá nên nó

là những yếu tố hết sức quan trọng để quyết định đến sự thành công hay thất

bại của 1 phần mềm.

1.1.2.2 Chất lượng bên trong

Những yếu tố chất lượng bên trong là những yếu tố “trong suốt” với

người dùng, chỉ những người phát triển (developer) mới thấy được.

Những yếu tố này là những tài liệu tham gia vào quá trình phát triển

phần mềm, như: tài liệu phân tích yêu cầu, tài liệu thiết kế,…và đoạn code.Tuy

yếu tố chất lượng bên ngoài là mục tiêu cuối cùng nhưng yếu tố bên trong lại

giúp đỡ những người phát triển đạt được sự cải tiến về chất lượng bên ngoài.

1.1.3 Cái nhìn chung về công nghệ phần mềm

1.1.3.1 Nhân tố con người

Nhân tố con người đóng 1 vai trò hết sức quan trọng trong CNPM, đến

nỗi mà viện CNPM đã phát triển “mô hình tính trưởng thành về khả năng quản

lý con người” (people management capability maturity model: PM-CMM). Mô

GV: Pham Thị Minh Thương

4

Bài giảng Công Nghệ Phần Mềm

hình này được phát triển để làm tăng tính sẵn sàng của tổ chức phần mềm trong

việc đảm trách những ứng dụng phức tạp ngày càng gia tăng bằng cách thu hút,

phát triển, thúc đẩy, triển khai, và giữ lại những tài năng cần thiết để cải tiến

khả năng phát triển phần mềm.

A.

Những người tham gia trong dự án phần mềm

Có thể chia ra thành 5 loại như sau:

A1. Senior Managers: định nghĩa ra những chiến lược kinh doanh và có

những ảnh hưởng đáng kể đến dự án.

A2. Project (Technical) Managers: lập kế hoạch, thúc đẩy tinh thần làm

việc, tổ chức và kiểm soát những thành viên làm công việc phần mềm.

A3. Practitioners: vận dụng những kỹ năng kỹ thuật của mình để làm

sản phẩm hay ứng dụng.

A4. Customers: đưa ra những yêu cầu phần mềm và những stakeholders

khác.

A5. End-users: sử dụng phần mềm khi phần mềm đưa ra sử dụng.

Để đạt được hiệu quả, đội dự án phải được tổ chức sau cho có thể sử

dụng được tối đa những khả năng và kỹ năng của mỗi người. Và đây chính là

công việc của team leader.

B.

Project manager (PM), Project leader (PL) và Team leader (TL)

Trong một cuốn sách của mình, Jerry Weinberg đã đề nghị ra mô hình

MOI cho bộ phận lãnh đạo.

Motivation (tính thúc đẩy, động lực): đây là khả năng thúc đẩy, động

viên những thành viên kỹ thuật để có thể sử dụng những khả năng tốt nhất của

họ cho việc sản xuất ứng dụng.

Organization (tính tổ chức): là khả năng sử dụng những tiến trình đang

tồn tại để tạo ra sản phẩm cuối cùng.

Ideas or innovation (sáng kiến và sự cải tiến mới): là khả năng thúc

đẩy, động viên tính sáng tạo của mọi người, mặc dù họ làm trong những giới

hạn đã được thiết lập.

GV: Pham Thị Minh Thương

5

Bài giảng Công Nghệ Phần Mềm

Đối với 1 problem gặp phải, leader và manager phải hiểu rõ được vấn đề

để có thể đưa ra hướng giải quyết xác đáng và thích hợp nhất. Chính vì vậy,

người leader hay manager có hiệu quả được nhấn mạnh ở 4 điểm chính sau:

Problem solving (giải quyết vấn đề): PM hiệu quả có thể phân tích

những vấn đề kỹ thuật và tổ chức, đưa ra giải pháp, áp dụng những bài học từ

những dự án trước trong tình trạng mới, đủ linh hoạt để thay đổi hướng giải

quyết nếu sự cố gắng ban đầu để giải quyết vấn đề không thu được hiệu quả.

Managerial identity (đặc tính quản lý): 1 PM giỏi phải chịu trách

nhiệm đối với dự án, phải biết nắm lấy quyền kiểm soát khi cần thiết và cho

phép các thành viên phát huy khả năng kỹ thuật của mình.

Achievement (thành tích): để tối ưu hóa năng suất của đội dự án, người

quản lý phải khen thưởng bằng những hành động thiết thực khi đội hoàn thành

dự án, và đối với những người gây ra rủi ro cho dự án sẽ không bị trừng phạt

nặng.

Influence and team building (ảnh hưởng và xây dựng đội): 1 PM hiệu

quả phải hiểu được thành viên trong đội của mình đang muốn gì và có phản

ứng trở lại với những nhu cầu đó.

C.

Đội phần mềm (software team)

Cấu trúc đội dự án tùy thuộc vào cách quản lý của tổ chức, số lượng

người tham gia vào đội, mức độ kỹ năng của từng người và độ khó của vấn đề.

Mantei đề xuất hướng tổ chức đội thành 3 loại sau:

Democratic decentralized (DD) (phân quyền dân chủ): đội này sẽ

không có leader lâu dài. Các leader sẽ được thay thế nhau theo từng task.

Những quyết định về vấn đề và các phương pháp thực thi được đưa ra dựa vào

sự nhất trí của nhóm. Việc giao tiếp, truyền thông giữa các thành viên trong

nhóm là ngang hàng nhau.

Controlled decentralized (CD) (phân quyền có kiếm soát): đội loại này

sẽ có 1 leader chịu trách nhiệm về những task cụ thể và leader thứ hai sẽ chịu

trách nhiêm về những task con. Việc giải quyết vấn đề là hoạt động chung của

cả nhóm, tuy nhiên việc thực hiện từng giải pháp lại là công việc của từng

nhóm con. Việc giao tiếp, truyền thông giữa các nhóm con và các thành viên là

GV: Pham Thị Minh Thương

6

Bài giảng Công Nghệ Phần Mềm

ngang hàng nhau. Việc truyền thông phân cấp cũng xuất hiện theo sự phân cấp

quyền kiểm soát.

Controlled centralized (CC) (tập trung kiểm soát): việc giải quyết vấn

đề ở mức độ cao nhất và sự điều phối trong nội bộ team được quản lý bởi TL.

Việc giao tiếp, truyền thông giữa các leader và các thành viên trong nhóm là

theo chiều dọc (có phân cấp).

Tuy nhiên, để lên được cấu trúc của đội thì 7 nhân tố sau nên được xem

xét:

-

Độ khó của vấn đề cần giải quyết.

Kích thước của chương trình theo từng dòng code và từng đoạn chức

năng.

-

Thời gian mà đội sẽ làm việc cùng với nhau.

Mức độ/ trình độ để mô hình hóa vấn đề.

Chất lượng đòi hỏi và độ tin cậy của hệ thống xây dựng.

Tính khắt khe của ngày giao.

Mức độ truyền thông đòi hỏi trong nhóm.

Bởi cấu trúc tập trung hoàn thành task nhanh hơn, nên nó thích hợp nhất

trong việc kiểm soát những vấn đề đơn giản. Những đội được phân quyền tạo

ra nhiều giải pháp và những giải pháp này thì tốt hơn là từng cá nhân nghĩ ra.

Hơn nữa, những đội này có khả năng thành công hơn trong việc giải quyết

những vấn đề khó. Vì vậy, đội CD được tập trung cho việc giải quyết vấn đề,

cấu trúc đội CD hay CC có thể được áp dụng thành công đối với những vấn đề

đơn giản. Cấu trúc DD thì tốt nhất cho những vấn đề khó.

Cấu trúc CC hay CD thường được giao cho những dự án rất lớn khi

những nhóm con có thể hoàn thành task dễ dàng.

Thời gian sống của đội ảnh hưởng đến tinh thành làm việc của đội. Cấu

trúc đội DD cho tinh thần làm việc và độ hài lòng công việc cao và vì vậy tốt

cho đội là sống trong 1 thời gian dài.

Để đội đạt được sự thực thi cao thì:

-

Các thành viên trong đội phải tin tưởng lẫn nhau.

Sự phân phối các kỹ năng phải thích hợp với vấn đề.

GV: Pham Thị Minh Thương

7

Bài giảng Công Nghệ Phần Mềm

-

Những khuyết điểm trong đội phải được loại trừ để duy trì sự gắn kết

của đội.

D.

Vấn đề điều phối và truyền thông (coordination and communication

issue)

Những phần mềm ngày nay có những đặc tính sau:

-

Scale (tính tỷ lệ): tỷ lệ của sự cố gắng phát triển phần mềm thì lớn, dẫn

đến độ phức tạp, sự mơ hồ và độ khó đáng kể trong việc điều hướng

những thành viên trong đội.

-

Uncertainty (tính bất định): sự bất định của phần mềm thì phổ biến, dẫn

đến chuỗi thay đổi tiếp diễn mà ảnh hưởng đến đội dự án.

Interoperability (khả năng tương tác): trở thành đặc trưng chính của

nhiều hệ thống. Phần mềm mới phải tương tác với phần mềm cũ và phù

hợp với những ràng buộc đã được nêu ra trước được chỉ ra bởi hệ thống

và sản phẩm.

Để giải quyết những đặc tính này 1 cách hiệu quả, đội CNPM phải xây

dựng những phương pháp hiêu quả cho việc điều hướng các thành viên. Để

hoàn thành điều đó, cơ cấu truyền thông/ giao tiếp thân mật và lịch sự giữa các

thành viên và giữa các đội phải được thiết lập.

Kraul và Streeter xem xét 1 tập hợp những kỹ thuật điều hướng dự án và

phân loại thành 5 loại sau:

-

Formal, impersonal approaches (phương thức lịch sự, khách quan):

gồm tài liệu kỹ thuật phần mềm và giao nộp (source code), ghi chú kỹ

thuật, các mốc dự án, lịch biểu và những công cụ kiểm soát dự án,

những yêu cầu thay đổi và những tài liệu liên quan, những báo cáo lưu

vết lỗi, và dữ liệu dự án.

-

Formal, interpersonal procedures (những thủ tục lịch sự, giữa các cá

nhân): tập trung vào những hoạt động đảm bảo chất lượng, áp dụng cho

những sản phẩm công việc CNPM, bao gồm review meetings, design

and code inspections.

GV: Pham Thị Minh Thương

8

Bài giảng Công Nghệ Phần Mềm

-

Informal, interpersonal procedures (những thủ tục thân mật, giữa các

cá nhân): gồm những cuộc họp nhóm để phổ biến thông tin, giải quyết

vấn đề và “sự sắp xếp yêu cầu và đội phát triển”.

-

Electronic communication (truyền thông điện tử): gồm email, bảng tập

san điện tử, hội nghị qua video.

Interpersonal networking (mạng giữa các cá nhân): gồm những cuộc

thảo luận thân mật giữa các thành viên trong và ngoài dự án (những

thành viên có kinh nghiệm và sự hiểu biết có thể hỗ trợ những thành

viên trong đội dự án).

1.1.3.2 Các loại phần mềm

Ngày nay, phần mềm được áp dụng ngày càng rộng rãi, trong bất kỳ một

hoàn cảnh nào. Nội dung thông tin và sự rõ rang là những nhân tố quan trọng

trong việc xác định bản chất của một phần mềm ứng dụng.

Nội dung thông tin đề cập đến ý nghĩa và hình thức thông tin vào và ra.

Các phần mềm ứng dụng trong doanh nghiệp sử dụng dữ liệu đầu vào có cấu

trúc cao (database) để tạo ra những báo cáo có định dạng.

Trong khi đó, sự rõ ràng của thông tin đề cập đến những dự đoán của

trình tự và thời gian của thông tin. Một chương trình phân tích kỹ nghệ chấp

nhận dữ liệu có trình tự đã được xác định trước và thực hiện những thuật toán

phân tích mà không gián đoạn và đưa ra kết quả trong báo cáo hay những định

dạng đồ họa.

Dựa vào mục đích sử dụng và bản chất của phần mềm mà phân mềm

được chia ra thành những loại sau:

-

System software (phần mềm hệ thống): là một tập hợp các chương trình

được viết để phục vụ các chương trình khác, như: drivers, compilers,

editors,…

-

Real-time software (phần mềm thời gian thực): là phần mềm giám sát,

phân tích và kiểm soát những sự kiện xảy ra trong thế giới thực khi nó

xảy ra. Các yếu tố của phần mềm thời gian thực là: (1) thu thập thông tin

từ bên ngoài (2) phân tích và chuyển đổi thông tin vào trong ứng dụng

GV: Pham Thị Minh Thương

9

Bài giảng Công Nghệ Phần Mềm

(3) kiểm soát dữ liệu đầu ra (4) giám sát các sự kiện bên ngoài để duy trì

sự phản ánh một cách chính xác.

-

Business software (phần mềm nghiệp vụ): là phần mềm xử lý các thông

tin của doanh nghiệp. Các hệ thống rời rạc (tính lương, các khoản thu

chi,…) đã phát triển thành phần mềm MIS(Management Information

System) truy cập một số lương lớn thông tin của doanh nghiệp.

Engineering and scientific software (phần mềm khoa học và ứng dụng):

là phần mềm sẽ sử dụng các thuật toán để phân tích và chuyển đổi các

con số.

-

Embedded software (phần mềm nhúng): là phần mềm nằm trong ROM

(read-only memory) và dùng để kiểm soát sản phẩm và hệ thống.

Personal computer software (phần mềm máy tính cá nhân)

Web-based software (phần mềm ứng dụng web)

-

Artificial Intelligence software (phần mềm trí tuệ nhân tạo): là phần

mềm sử dụng các thuật toán không số (non-numerical algorithms) để

giải quyết các vấn đề phức tạp, không tuân theo quy luật nào, như: hệ

thống nhận dạng mô hình (âm thanh, hình ảnh), mạng lưới thần kinh

nhân tạo (artificical neural networks).

1.1.3.3 Tiến trình phần mềm (software process)

A.

Tổng quan về tiến trình phần mềm

Tiến trình phần mềm là một tập hợp các hoạt động để sản xuất phần

mềm. Những hoạt động này liên quan đến việc phát triển phần mềm từ những

thứ lộn xộn vào trong ngôn ngữ lập trình chuẩn như java, C. Tuy nhiên, những

phần mềm mới đa số được phát triển bằng cách mở rộng hay nâng cấp những

phần mềm đang tồn tại.

Những tiến trình phần mềm thì phức tạp và cũng giống như tất cả những

tiến trình thông minh và có tính sáng tạo khác, tiến trình phần mềm cũng dựa

vào những người đưa ra quyết định và sự chuẩn đoán. Bởi sự cần thiết của việc

chuẩn đoán và sự sáng tạo nên họ đang ra sức cố gắng tự động hóa những tiến

trình phần mềm đáp ứng được sự thành công có giới hạn. Những công cụ Công

Nghệ Phần Mềm Hỗ Trợ Máy Tính (Computer-aided software engineering

GV: Pham Thị Minh Thương

10

Bài giảng Công Nghệ Phần Mềm

CASE) có thể hỗ trợ một số họat động tiến trình. Tuy nhiên, ít nhất là trong

một vài năm nữa, vẫn không có khả năng cho sự tự động hóa mở rộng hơn, ở

đó phần mềm đảm nhận việc thiết kế của những kỹ sư liên quan đến tiến trình

phần mềm.

Một lý do, sự hiệu quả của những công cụ CASE bị giới hạn do có quá

nhiều tiến trình phần mềm. Không có tiến trình lý tưởng nào và nhiều tổ chức

lại phát triển những tiến trình của riêng họ để phát triển phần mềm. Những tiến

trình này được đưa ra để khai thác khả năng của con người trong tổ chức và

những đặc tính cụ thể của hệ thống mà họ đang phát triển. Đối với một số hệ

thống, như những hệ thống quan trọng, một tiến trình phát triển được cấu trúc

thì được đòi hỏi. Đối với những hệ thống thương mại, với những yêu cầu bị

thay đổi một cách nhanh chóng, một tiến trình nhanh nhẹn và linh hoạt thì có

vẻ hiệu quả hơn.

Mặc dù có nhiều tiến trình phần mềm, một số hoạt động nền tảng thì phổ

biến chung cho tất cả các tiến trình.

1. Đặc tả phần mềm (Software specification): chức năng của phần mềm và

những ràng buộc trong họat động của nó phải được định nghĩa.

2. Thiết kế và thực thi phần mềm (Software design and implementation):

phần mềm đáp ứng đặc tả phải được tạo ra.

3. Chứng nhận phần mềm: phần mềm phải được chứng nhận để đảm bảo

rằng nó làm những gì mà khách hàng muốn.

4. Tiến triển phần mềm: phần mềm phải tiến triển để đáp ứng những nhu

cầu thay đổi của khách hàng.

Mặc dù không có một tiến trình phần mềm nào lý tưởng, nhưng lại có

phạm vi cho việc cải tiến những tiến trình phần mềm trong các tổ chức. Những

tiến trình này có thể bao gồm những kỹ thuật chưa được cập nhật. Thực vậy,

nhiều tổ chức vẫn không có được sự thuận lợi nào của những phương pháp

công nghệ phần mềm trong sự phát triển phần mềm của họ.

Những tiến trình phần mềm có thể được cải tiến bằng sự chuẩn hóa tiến

trình ở nơi mà sự đa dạng trong các tiến trình phần mềm trên tổ chức thì được

giảm bớt. Điều này dẫn đến sự truyển thông được cải tiến và sự giảm bớt trong

GV: Pham Thị Minh Thương

11

Bài giảng Công Nghệ Phần Mềm

thời gian huấn luyện và làm cho sự hỗ trợ tiến trình được tự động hóa tiết kiệm

hơn. Sự chuẩn hóa cũng là một bước đầu quan trọng trong việc giới thiệu

những phương pháp và kỹ thuật công nghệ phần mềm mới và áp dụng công

nghệ phần mềm được tốt.

B.

models)

Mô hình tiến trình phần mềm là đại diện trừu tượng cho tiến trình phần

Tổng quan về những mô hình tiến trình phần mềm (software process

mềm. Mỗi mô hình tiến trình đại diện cho một tiến trình từ một tiến độ cụ thể,

vì vậy chỉ cung cấp cho bạn được môt phần thông tin về tiến trình mà thôi.

Những mô hình chung không phải là sự định nghĩa cuối cùng của những

tiến trình phần mềm. Đúng hơn, chúng là sự trừu tượng của tiến trình mà có thể

được dùng để giải thích những phương pháp khác nhau của sự phát triển phần

mềm. Chúng như một khung tiến trình mà có thể được mở rộng và gắn vào để

tạo ra nhiều tiến trình CNPM hơn.

Tất cả sự phát triển phần mềm có thể được đặc trưng như một vòng lặp

giải quyết vấn đề gồm 4 giai đoạn riêng biệt sau: status quo (trích dẫn tình

trạng), problem definition (định nghĩa vấn đề), technical development (phát

triển kỹ thuật), solution integration (tích hợp giải pháp).

Status quo: miêu tả tình trạng hiện tại của công việc.

Problem definition: chỉ ra những vấn đề cụ thể cần được giải quyết.

GV: Pham Thị Minh Thương

12

Bài giảng Công Nghệ Phần Mềm

Technical development: giải quyết vấn đề bằng cách áp dụng một số kỹ

thuật công nghệ.

Solution integration: đưa ra kết quả của việc giải quyết vấn đề cho

những người yêu cầu thông qua tài liệu, chương trình, dữ liệu, chức năng

nghiệp vụ mới.

Các pha và các bước chung của CNPM đều có thể dễ dàng nối (map) với

những giai đoạn này.

Vòng lặp giải quyết vấn đề này có thể được áp dụng cho các cấp độ khác

nhau của công việc CNPM. Nó có thể được sử dụng ở cấp độ marco khi mà

ứng dụng chỉ đang trong giai đoạn xem xét, ở cấp độ mid-level khi những

thành phần chương trình đang được phác thảo, và thậm chí là ở những dòng

code của cấp độ code. Vì vậy, sự đại diện phân dạng có thể cung cấp một cái

nhìn lý tưởng hóa của tiên trình. Do đó, trong mỗi giai đoạn của vòng lặp giải

quyết vấn đề chứa đựng một vòng lặp giải quyết vấn đề đồng nhất.

Tuy nhiên, thật khó để chia những hoạt động này ra một cách gọn gàng

như ở trên trong thực tế.

Raccoon đề nghị một “mô hình hỗn loạn” (Chaos model) mà miêu tả

“sự phát triển phần mềm như là một sự liên tục từ người dùng đến các nhà phát

triển và đến công nghệ” (“software development [as] a continuum from the

user to the developer to the technology”). Khi những tiến trình công việc hướng

GV: Pham Thị Minh Thương

13

Bài giảng Công Nghệ Phần Mềm

đến một hệ thống hoàn chỉnh, các giai đoạn được áp dụng một cách đệ quy với

những nhu cầu của người dùng và các đặc tả kỹ thuật của phần mềm của các

nhà phát triển.

Hiện nay có nhiều mô hình CNPM khác nhau và mỗi cách được đặc

trưng trong một cách mà hỗ trợ một cách lý tưởng trong việc kiểm soát và điều

phối một dự án phần mềm.

Một số mô hình phần mềm:

-

Mô hình thác nước (the waterfall model)

Mô hình mẫu (the prototyping model)

Mô hình phát triển ứng dụng nhanh RAD (the rapid application

development model)

-

Mô hình tiến hóa (evolutionary development model)

+ Mô hình gia tăng (incremental model)

+ Mô hình xoắn ốc (the spiral model)

+ Mô hình xoắn ốc WINWIN (the WINWIN spiral model)

Trong thực tế những mô hình này không loại trừ lẫn nhau mà thường

được kết hợp lẫn nhau đặc biệt là cho sự phát triển những hệ thống lớn. Những

hệ thống con trong hệ thống lớn có thể được phát triển bằng cách sử dụng

những phương pháp khác nhau.

C.

Các mô hình phần mềm (software models)

C1. Mô hình thác nước (Waterfall model)

GV: Pham Thị Minh Thương

14

Bài giảng Công Nghệ Phần Mềm

Định nghĩa và Phân

tích các

yêu cầu

Thiết kế phần mềm

và hệ thống

Thực thi và kiểm thử

từng đơn vị

Tích hợp và kiểm

thử toàn bộ hệ thống

Đưa vào hoạt động

và bảo trì

Đây là mô hình đầu tiên của CNPM, nó được lấy từ nhiều tiến trình kỹ

nghệ phần cứng. Do tính phân tầng đi từ pha này đến pha khác, nên mô hình

này được gọi là mô hình thác nước, mô hình tuyến tính hay chu kỳ sống của

phần mềm. Những giai đoạn cơ bản của mô hình đều phù hợp với những hoạt

động phát triển chung:

-

Định nghĩa và phân tích yêu cầu (Requirements analysis and definition):

hệ thống dịch vụ, những rang buộc và những mục tiêu được thiết lập

bằng cách thảo luận với người dung hệ thống. Sau đó chúng sẽ được

định nghĩa và xem xét như đặc tả hệ thống mà cả nhà phát triển và người

dung đều có thể hiểu được.

-

Thiết kế phần mềm và hệ thống (System and software design): giai đoạn

này sẽ phân yêu cầu ra thành những yêu cầu của hệ thống hay của phần

mềm. Nó sẽ xây dựng một cấu trúc hệ thống tổng thể. Thiết kế phần

GV: Pham Thị Minh Thương

15

Bài giảng Công Nghệ Phần Mềm

mềm bao gồm việc định nghĩa và miêu tả sự trừ tượng hóa hệ thống

phần mềm và mối quan hệ của chúng.

-

Thực thi và kiểm thử từng đơn vị (Implementation and testing unit):

trong suốt giai đoạn này, bản thiết kế phần mềm được xem như là một

tập hợp các chương trình đơn vị. Kiểm thử đơn vị sẽ chứng nhận rằng

từng đơn vị có đúng như với đặc tả không.

Tích hợp và kiểm thử toàn bộ hệ thống (Integration and system testing):

từng đơn vị của chương trình thì được tích hợp và kiểm thử như một hệ

thống hoàn chỉnh để đảm bảo chương trình đáp ứng được yêu cầu khách

hang. Sau khi kiểm thử, hệ thống phần mềm được giao đến khách hang.

Đưa vào hoạt động và bảo trì (Operation and maintance): đây là giai

đoạn lâu nhất trong chu kỳ sống của phần mềm. Hệ thống được cài đặt

và đưa vào sử dụng thực tế. Công viêc bảo trì lien quan đến việc sửa lỗi

chưa được phát hiện ở những giai đoạn trước và nâng cấp hệ thống.

Từng giai đoạn đều tạo ra 1 hay nhiều tài liệu cần phải được chấp thuận.

Những giai đoạn sau không nên bắt đầu cho đến khi giai đoạn trước nó được

hoàn thành. Trong thực tế, những giai đoạn này gối lên nhau và phản hồi thông

tin với nhau. Suốt giai đoạn thiết kế, những vấn đề về yêu cầu được chỉ ra. Suốt

giai đoạn code, những vấn đề về thiết kế được đưa ra ,…. Tiến trình phần mềm

không phải là 1 mô hình tuyến tính đơn giản mà là 1 chuỗi lặp lại của những

họat động phát triển phần mềm.

Suốt giai đoạn cuối của chu trình sống (operation and maintance), phần

mềm được đưa vào sử dụng. Những lỗi và sự thiếu sót trong yêu cầu được phát

hiện. Những lỗi chương trình và thiết kế xuất hiện và nhu cầu cần có một chức

năng mới được đưa ra.

Điểm thuận lợi của mô hình thác nước là các tài liệu được đưa ra ở từng

giai đoạn và các tài liệu này phù hợp với các mô hình tiến trình kỹ nghệ khác.

Vấn đề chính yếu của nó đó là sự phân vùng không linh hoạt của nó để đưa vào

từng giai đoạn riêng biệt. Sự cam kết phải được làm ở giai đoạn sớm của tiến

GV: Pham Thị Minh Thương

16

Bài giảng Công Nghệ Phần Mềm

trình, điều này gây khó khăn cho sự hồi đáp những thay đổi trong yêu cầu của

khách hàng.

Do đó, mô hình thác nước chỉ nên được dùng khi yêu cầu đã được hiểu

rõ ràng và sự thay đổi yêu cầu trong suốt giai đoạn phát triển phần mềm là

không nghĩ đến. Thực tế, mô hình thác nước vẫn còn được sử dụng nhiều, đặc

biệt khi dự án phần mềm là một phần của dự án kỹ nghệ hệ thống lớn hơn.

Tóm lại, những điểm yếu của mô hình thác nước như sau:

-

Thực tế các dự án ít khi nào tuân theo dòng tuần tự của mô hình mà

thường lặp lại.

-

Khách hàng hiếm khi nói rõ ràng các yêu cầu.

Khách hàng thường phải chờ lâu mới thấy được phiên bản đầu tiên của

phần mềm.

C2. Mô hình chữ V (V model)

Sinh viên tự nghiên cứu.

C3. Mô hình mẫu (Prototyping model)

Thông thường, khách hàng định nghĩa 1 tập hợp các mục tiêu chung của

phần mềm, nhưng lại không chỉ rõ những yêu cầu đầu vào, xử lý, đầu ra. Trong

những trường hợp đó, nhà phát triển có thể không đảm bảo được tính hiệu quả

của thuật toán, khả năng tương thích của hệ điều hành hay hình thức tương tác

giữa con người và máy tính cần có. Trong những tình huống này và nhiều tình

huống khác, mô hình mẫu là phương pháp lựa chọn tốt nhất.

Mục tiêu của việc phát triển dựa vào mẫu thử là giải quyết 2 hạn chế đầu

tiên của mô hình thác nước. Ý tưởng cơ bản ở đây là thay cho việc chốt lại yêu

cầu trước khi thiết kế hay code, một mẫu thử có tính sử dụng 1 lần được xây

dựng để hiểu yêu cầu. Mẫu thử được xây dựng dựa vào những yêu cầu được

biết hiện tại. Việc phát triển mẫu thử này dĩ nhiên cũng trải qua các giai đoạn

design, coding, testing. Nhưng mỗi pha không được thực hiện một cách chu

đáo. Bằng việc sử dụng mẫu thử, khách hàng sẽ có được cảm giác một hệ thống

thực sự, vì khi tương tác với mẫu thử, khách hàng sẽ biết được rõ hơn những

yêu cầu của hệ thống mong muốn.

GV: Pham Thị Minh Thương

17

Bài giảng Công Nghệ Phần Mềm

Mẫu thử là ý tưởng đầy hấp dẫn cho những hệ thống lớn, phức tạp và tự

động. Trong những trường hợp này, khách hàng được để cho lập kế hoạch làm

việc với mẫu thử, cung cấp những dữ liệu đầu vào, qua đó giúp xác định yêu

cầu cho hệ thống.

Bắt đầu

Tập hợp yêu

Thiết kế

Xây dựng

cầu

nhanh

mẫu thử

Kết thúc

Sản phẩm kỹ

thuật

Tinh lọc mẫu

Đánh giá của

khách hàng

thử

Tóm lại, mô hình mẫu thử có những ưu, nhược điểm sau:

Ư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

thông qua giao diện của ứng dụ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 thử không chuyển tải được 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.

-

Mẫu thử thường được làm nhanh, thậm chí vội vàng theo kiểu “làm –

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.

C4. Mô hình tăng dần (Incremental model)

Mô hình tăng dần kết hợp những yếu tố của mô hình tuyến tính (mô

hình thác nước) và ý tưởng lặp của chế bản mẫu. Mô hình tăng dần phân phối

phần mềm ra thành các mảnh (piece) nhỏ nhưng có tính tiện dụng, gọi là “các

phần tăng trưởng” (increments). Nhìn chung, mỗi phần tăng trưởng được xây

dựng trên những cái đã được phân phối.

GV: Pham Thị Minh Thương

18

Bài giảng Công Nghệ Phần Mềm

Khi mô hình tăng dần được sử dụng, phần tăng trưởng đầu tiên gọi là

sản phầm lõi. Sản phẩm lõi với những chức năng cơ bản nhất sẽ được lên kế

hoạch và thực hiện đầu tiên. Kế hoạch này cũng chỉ ra việc sửa đổi sản phẩm

lõi để đáp ứng nhu cầu của khách hàng và giao các chức năng, tính năng thêm

vào tốt hơn. Tiến trình này được lặp lại sau việc giao mỗi lần tăng trưởng cho

đến khi sản phần hoàn chỉnh được tạo ra.

C5. Mô hình xoắn ốc (Spiral model)

Mô hình xoắn ốc được Boehm đề xuất vào năm 1988. Đây là mô hình

kết hợp tính lặp của mô hình mẫu với những khía cạnh được kiểm soát và hệ

thống hóa của mô hình tuyến tính.

Mô hình xoắn ốc được chia ra thành nhiều hoạt động chính, điển hình là

từ 3 đến 6 hoạt động. Sau đây là mô hình với 6 hoạt động chính:

GV: Pham Thị Minh Thương

19

Bài giảng Công Nghệ Phần Mềm

Customer communication (giao tiếp với khách hàng): thiết lập sự

giao tiếp có hiệu quả giữa người phát triển và khách hàng.

Planning (lập kế hoạch): xác định tài nguyên, thời hạn và các thông tin

khác.

Risk analysis (phân tích rủi ro): xem xét cả rủi ro kỹ thuật và rủi ro

quản lý.

Engineering (kỹ thuật): xây dựng một hay một số biểu diễn của ứng

dụng.

Construction & release (xây dựng và phát hành): xây dựng, kiểm

thử, cài đặt và cung cấp hỗ trợ người dùng (tư liệu, huấn luyện,…).

Customer evaluation (đánh giá của khách hàng): nhận các phản hồi

của người dùng về biểu diễn phần mềm trong giai đoạn kỹ thuật và cài đặt.

Khi tiến trình bắt đầu, đội CNPM sẽ di chuyển vào trong xoắn ốc theo

chiều kim đồng hồ, bắt đầu là ở tâm. Mô hình xoắn ốc được áp dụng xuyên

suốt chu kỳ sống của phần mềm. Mỗi khối lập phương đặt tại trục tọa độ đại

diện cho điểm bắt đầu của mỗi loại dự án khác nhau. “Concept development

projects” bắt đầu ở lõi của xoắn ốc và tiếp tục cho đến khi sự phát triển khái

GV: Pham Thị Minh Thương

20