Chương V: Quy trình làm phần mềm docx

CHƯƠNG V – QUI TRÌNH LÀM PHẦN MỀM.

1. MỞ ĐẦU

Quy trình làm phần mềm (hay gọi đơn giản theo tiếng Anh: software

process - quy trình phần mềm) là quá trình tạo ra phần mềm. Quy trình này là sự

kết hợp mô hình vòng đời phần mềm, các công cụ được sử dụng và quan trọng

hơn hết, là những người xây dựng nên phần mềm đó. Các công ty phần mềm

khác nhau có các quy trình phần mềm khác nhau. Ví dụ hãy xem vấn đề tài liệu.

Có một số công ty cho rằng chính bản thân phần mềm với các mã nguồn là tài

liệu về phần mềm. Họ cho rằng phần mềm có thể hiểu được bằng cách đọc các

mã nguồn này. Một số công ty khác chuẩn bị tài liệu rất chi tiết. Ngay cả khi

phần mềm đã cài đặt cho khách hàng và chuyển sang giai đoạn bảo trì, thì mọi sự

sửa đổi phần mềm cũng được ghi chép lại, các bản thiết kế cũng được thay đổi

cho phù hợp. Từ thực tế có thể thấy rằng một phần mềm được kiểm thử kỹ lưỡng

và có các tài liệu báo cáo đầy đủ trong từng pha thì chất lượng sẽ tốt hơn và

công việc bảo trì cũng thuận lợi hơn.

Nói chung, một quy trình phần mềm thường trải qua 7 pha: xác định yêu

cầu, phân tích, thiết kế, cài đặt, tích hợp, bảo trì và thôi sử dụng. Trong một số

trường hợp thì tên các pha này có thể khác. Ví dụ người ta hợp nhất hai pha xác

định yêu cầu và phân tích thành pha phân tích hệ thống. Một vài pha khác lại

được chia nhỏ hơn, ví dụ pha thiết kế được chia thành pha thiết kế kiến trúc và

thiết kế chi tiết. Hai pha cài đặt và tích hợp được kết hợp thành pha cài đặt và

tích hợp. Những lý do sau đây trả lời câu hỏi vì sao các pha của vòng đời phần

mềm cần được kiểm thử kỹ và báo cáo thành tài liệu chi tiết bởi nhóm thực hiện

trước khi tiến hành các pha tiếp theo:

- Vì sự thúc ép về thời gian hoàn thành nên những phần tài liệu bị trì hoãn

thường ít khi được tiếp tục hoàn thiện.

- Trách nhiệm về một pha nào đó có thể được chuyển giao cho nhóm khác

thậm chí ở một công ty phần mềm khác.

- Phần mềm thường liên tục thay đổi trong quá trình xây dựng. Ví dụ thiết

kế có thể bị thay đổi trong pha cài đặt. Rõ ràng nếu tài liệu thiết kế được biên

soạn đầy đủ thì sự sửa đổi sẽ thuận lợi hơn.

99

II. CÁC ĐỐI TƯỢNG

1. Khách hàng

Khách hàng là cá nhân hoặc công ty có nhu cầu sử dụng phần mềm.

2. Người phát triển

Những người phát triển là những người nhận trách nhiệm xây dựng

phần mềm do khách hàng yêu cầu.

3. Người sử dụng

Người sử dụng là người trực tiếp sử dụng phần mềm khi nó được cài

đặt cho khách hàng.

Khách hàng, người phát triển và người sử dụng có thể ở các công ty khác

nhau hoặc ở ngay trong một công ty. Cũng có khi họ là những người lao động tự

do. Thường thì khách hàng và người sử dụng ở cùng một công ty, còn những

người phát triển là thành viên của một công ty phần mềm nào đó. Nếu xét về mặt

giá cả thì người ta phân các phần mềm thành hai loại: Phần mềm được xây dựng

cho một khách hàng thường có giá cao, và phần mềm đóng gói được bán cho

nhiều khách hàng ví dụ như Microsoft Word, Microsoft Excel...thường có giá rẻ

hơn.

Trong những lần gặp đầu tiên giữa khách hàng và người phát triển, khách

hàng phác thảo các yêu cầu, chức năng, các công việc cần thực hiện của phần

mềm mà họ muốn đặt hàng. Theo cách nhìn nhận của người phát triển thì những

điều khách hàng mô tả có thể mơ hồ, có những điều không hợp lý, thậm chí mâu

thuẫn hay không khả thi. Nhiệm vụ của người phát triển là phải tìm hiểu xem

thực chất khách hàng cần gì. Ngoài những yêu cầu về chức năng và công việc,

họ còn phải tìm hiểu xem các điều kiện về phần mềm là gì? Ví dụ như phần mềm

phải hoàn thành trong thời gian bao lâu, phần mềm cần làm việc với hệ điều

hành nào, trên máy tính có cấu hình ra sao, giá cả khoảng bao nhiêu thì chấp

nhận được. Thường thì chính khách hàng hỏi lại người phát triển giá của phần

mềm, và người phát triển phải cân nhắc khi trả lời câu hỏi này.

III – PHA XÁC ĐỊNH YÊU CẦU

1. Nắm bắt yêu cầu

Quá trình khám phá các yêu cầu của khách hàng được gọi là sự nắm bắt

yêu cầu (requirements capture), hoặc sự gợi mở yêu cầu (requirements

100

elicitation) hay tìm hiểu vấn đề (concept exploration). Sau khi các yêu cầu được

xác định thì chúng được xem xét để hiệu chỉnh, lược bỏ bớt hoặc mở rộng. Quá

trình này được gọi là phân tích yêu cầu (requrements analysis). Pha yêu cầu

thường được bắt đầu bằng việc gặp gỡ trao đổi giữa một vài thành viên của

nhóm yêu cầu và một vài thành viên đại diện cho công ty khách hàng để cùng

nhau xác định xem sản phẩm phần mềm cần những gì. Cuộc trao đổi thường

được thực hiện theo cách là thành viên của nhóm yêu cầu đưa ra các câu hỏi có

tính gợi mở về lĩnh vực mà phần mềm được sử dụng. Các thành viên của công ty

khách hàng hoặc trả lời các câu hỏi của nhóm yêu cầu, hoặc chủ động nêu ra các

vấn đề mà họ cần. Rõ ràng, những thành viên tham gia khám phá yêu cầu của

khách hàng phải có hiểu viết về lĩnh vực mà phần mềm ứng dụng giải quyết, để

có thể hiểu được những điều khách hàng nói, và có thể đưa ra các câu hỏi có ý

nghĩa. Vì vậy, nhiệm vụ đầu tiên của nhóm yêu cầu chính là tìm hiểu và làm

quen với lĩnh vực ứng dụng của phần mềm mà khách hàng muốn có. Ví dụ, nếu

phần mềm là quản lý các chuyến bay của một hãng hàng không thì lĩnh vực cần

tìm hiểu là cách thức quản lý các chuyến bay của một hãng hàng không. Nếu

phần mềm là chương trình quản lý thư viện thì nhóm yêu cầu cần có hiểu biết

nhất định về lĩnh vực thư viện...Để sử dụng từ một cách chính xác, các thành

viên nhóm yêu cầu cần tìm hiểu các thuật ngữ. Ví dụ, nếu họ đang chuẩn bị làm

phần mềm trong lĩnh vực sinh học thì cần tìm hiểu các thuật ngữ về sinh học.

Một trong những phương pháp khắc phục vấn đề thuật ngữ là xây dựng bộ từ

vựng về lĩnh vực ứng dụng. Mỗi lần gặp một thuật ngữ mới thì nhóm yêu cầu

cần tìm hiểu để biết được một cách chính xác ý nghĩa và đưa thuật ngữ này vào

bộ từ vựng. Sau khi đã có những hiểu biết nhất định về lĩnh vực ứng dụng phần

mềm, các thành viên bắt đầu khám phá, tìm hiểu các yêu cầu khách hàng theo

các cách thức sau:

1.1. Phỏng vấn khách hàng

Có hai kiểu phỏng vấn: có cấu trúc (structured) và không có cấu trúc

(unstructured). Với kiểu phỏng vấn cấu trúc thì các câu hỏi đóng (close-ended)

và được chuẩn bị trước. Ví dụ như: "công ty sử dụng bao nhiêu nhân viên bán

hàng", "lương trung bình của các nhân viên trong công ty là bao nhiêu"... Trong

cách phỏng vấn không có cấu trúc thì các câu hỏi có tính mở (open-ended) được

đưa ra. Ví dụ: "Hãy nêu ra một vài điểm yếu của phần mềm đang sử dụng mà

101

khách hàng có ý định thay thế". Tuy nhiên, cũng không nên hỏi những câu quá

chung chung, khó trả lời như: "Hãy nói cho tôi biết về sản phẩm hiện tại". Các

câu hỏi mở nên đưa ra sao cho có thể khích lệ người được phỏng vấn có thể cho

câu trả lời trong một phạm vi rộng, tuy nhiên cũng không nên rộng quá mà chỉ

nằm trong phạm vi các thông tin cần nắm bắt. Phỏng vấn có hiệu quả là công

việc không dễ dàng. Điều kiện quan trọng đầu tiên là người phỏng vấn cần am

hiểu về lĩnh vực mà họ chuẩn bị phỏng vấn. Các câu hỏi đưa ra cũng phải hợp lý

để người được phỏng vấn có thể nói ra những thông tin có ích cần thiết một cách

tự nhiên, không bị gò ép hay e ngại gì. Đôi khi những câu hỏi quá thẳng thắn và

trực tiếp chưa chắc đã nhận được câu trả lời đúng. Ví dụ nếu hỏi rằng "lương anh

chị rất thấp, nhưng chi tiêu thì có vẻ rất nhiều. Anh chị hãy cho biết làm sao có

được khoản tiền ngoài lương kia..." thì thường là người được hỏi sẽ tìm cách né

tránh câu trả lời thật.

Sau khi phỏng vấn xong thì người phỏng vấn cần viết báo cáo về kết quả

phỏng vấn và nên đưa cho người được phỏng vấn xem và góp ý kiến.

1.2. Kịch bản (scenario)

Kịch bản là một kỹ thuật được sử dụng để phân tích yêu cầu. Kịch bản

là mô tả các thao tác cần thực hiện trên phần mềm cần xây dựng để hoàn thành

một công việc nào đó (trong các công việc mà phần mềm cung cấp).

1.3. Một vài kỹ thuật nắm bắt yêu cầu khác

Một kỹ thuật khác hay được sử dụng để nắm bắt các yêu cầu khách

hàng là gửi các bảng câu hỏi cho một số thành viên đại diện của công ty khách

hàng. Bằng cách này có thể gửi cho hàng trăm thành viên để nhận được các câu

trả lời dưới dạng viết, được suy nghĩ kỹ. Tuy nhiên, nếu từ bảng câu hỏi đã được

trả lời, người phỏng vấn có thể đưa ra thêm các câu hỏi thích hợp với người được

phỏng vấn thì có thể nhận được các thông tin bổ ích. Đôi khi các thông tin này

có ích hơn nhiều so với trả lời viết đã có.

Một cách khác để tìm hiểu và nắm bắt yêu cầu khách hàng, đặc biệt trong môi

trường kinh doanh, là xem xét các biểu mẫu khác nhau mà các khách hàng sử

dụng. Ví dụ, từ việc xem xét các biểu mẫu được in ra có thể biết được các dạng

báo cáo, cỡ giấy; tài liệu viết về cách thức điều hành hoặc mô tả công việc là

102

những công cụ rất hữu ích để giúp tìm ra công việc gì đang được thực hiện, và

được thực hiện như thế nào ở công ty khách hàng.

Gần đây, người ta thường áp dụng thêm một phương pháp nữa là quay băng

video cảnh làm việc ở công ty khách hàng (tất nhiên là được sự cho phép của

công ty và của những người được quay). Như vậy, có thể biết được chính xác

những gì đang xảy ra. Tuy nhiên, cách này có một nhược điểm là phải tốn khá

nhiều thời gian để xem lại băng và phân tích để rút ra những thông tin cần thiết.

Một nhược điểm rất lớn khác của phương pháp này là phần lớn những người

được quay đều không thích mình xuất hiện trong máy quay và trở nên dè dặt khi

hành động.

Sau khi thu được các thông tin ban đầu về yêu cầu khách hàng, bước tiếp theo

là phân tích các yêu cầu đó để rút ra những thông tin cơ bản nhất có thể giúp ích

cho việc xây dựng phần mềm.

2. Phân tích yêu cầu

Tới thời điểm này, nhóm yêu cầu đã có được tập hợp khởi đầu các yêu cầu

khách hàng. Các yêu cầu này được phân làm hai loại: chức năng (functional) và

phi chức năng (nonfunctional).

Yêu cầu chức năng thường gắn với chức năng tương ứng của phần mềm cần

xây dựng và thể hiện dưới dạng các mục chọn của thực đơn, ví dụ như: "Phần

mềm cung cấp chức năng tìm kiếm hàng hóa theo tên hàng và ngày bán". Đặc tả

phi chức năng dùng để chỉ rõ tính chất nào đó của phần mềm cần xây dựng, ví dụ

tính tin cậy và bảo trì được; hoặc liên quan đến môi trường mà phần mềm được

sử dụng, ví dụ: tất cả các mã khách hàng được nhập trực tiếp từ bàn phím và

được lưu trong một tệp bảng dữ liệu". Tóm lại yêu cầu chức năng là nói đến một

công việc cụ thể, thường thể hiện bằng các mục chọn trong chương trình; còn

yêu cầu phi chức năng thì nói về các tính chất của phần mềm, các tính chất này

không thể thể hiện được bằng một việc cụ thể. Thí dụ từ câu: "yêu cầu phần mềm

phải có giao diện đẹp, thân thiện với người sử dụng", ta không thể nói được cụ

thể là phải làm gì.

Một điều rất quan trọng là phần mềm phải theo dõi được (traceable). Điều

này có nghĩa là có thể kiểm tra xem tất cả các yêu cầu đã được thể hiện trong bản

đặc tả chưa; điểm nào trong bản báo cáo yêu cầu tương ứng với điểm nào trong

báo cáo đặc tả. Tương tự, báo cáo thiết kế hay chương trình cũng phải tương ứng

103

với các tài liệu trước đó. Như vậy, nhóm bảo đảm chất lượng phần mềm có thể

kiểm tra xem có phải tất cả các mục trong các yêu cầu khách hàng đã được thực

hiện hay chưa.

Tất cả các yêu cầu thu thập được ban đầu đều được đưa cho khách hàng xem

xét. Họ sẽ sắp xếp các mục yêu cầu theo thứ tự quan trọng, phát hiện và hiệu

chỉnh những điều không chính xác hoặc bỏ đi những mục không cần thiết...

Tiếp theo, nhóm yêu cầu sẽ thảo luận với những khách hàng đã được phỏng

vấn và xem xét lại các vấn đề một cách kỹ càng, xem có điều gì còn bị bỏ sót

không. Và như chúng ta biết, kỹ thuật phân tích yêu cầu hiệu quả và chính xác

nhất là làm bản mẫu, vì vậy nếu có thể thì nhóm chuyển qua bước làm bản mẫu

để đưa cho khách hàng xem xét một cách trực quan hơn.

3. Làm bản mẫu (prototyping)

Bản mẫu được xem là kỹ thuật phân tích yêu cầu chính xác nhất.

Bản mẫu là phần mềm được xây dựng nhanh chủ yếu để thể hiện các chức

năng quan trọng nhất của phần mềm cần xây dựng. Mục đích của bản mẫu là thể

hiện các yêu cầu khách hàng, do đó khi xây dựng người ta chú ý nhiều đến giao

diện và các báo cáo in ra. Những vấn đề quan trọng khác mà một phần mềm sản

phẩm cần phải có như tính bảo mật, an toàn dữ liệu, tốc độ tính toán, kiểm tra và

khắc phục lỗi... đều chưa được chú ý khi làm bản mẫu; nghĩa là bản mẫu chỉ là

thể hiện bên ngoài của sản phẩm và bỏ qua những phần được che dấu. Bản mẫu

được cài đặt để khách hàng sử dụng thử. Qua việc thao tác trực tiếp với bản mẫu,

họ sẽ thấy được các chức năng của phần mềm đã thể hiện đúng các yêu cầu của

họ chưa, cái gì cần thêm bớt hay hiệu chỉnh bổ sung. Những người phát triển sẽ

hiệu chỉnh bản mẫu cho đến khi khách hàng vừa ý và cho rằng mọi yêu cầu của

họ đã được bao hàm trong phần mềm (tất nhiên là về hình thức). Bản mẫu sẽ

được dùng làm cơ sở để biên soạn tài liệu đặc tả.

Như tên gọi của nó, bản mẫu nhanh (rapid prototype) được xây dựng với mục

đích để người phát triển và khách hàng thống nhất càng nhanh càng tốt những

điều mà sản phẩm chính cần làm. Như vậy, nhiều điều có thể bỏ qua khi làm bản

mẫu. Bản mẫu có thể thường xuyên gặp sự cố và phải khởi động lại; màn hình

nhập dữ liệu có thể chưa đẹp; báo cáo in ra còn thiếu biểu tượng công ty khách

hàng,...

104